* Re: ACPI error in 2.6.16
From: Andrew Morton @ 2006-03-23 2:34 UTC (permalink / raw)
To: Jiri Slaby; +Cc: biscani, linux-kernel, linux-acpi
In-Reply-To: <4421F834.1070602@liberouter.org>
Jiri Slaby <slaby@liberouter.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Francesco Biscani napsal(a):
> > Hello,
> >
> > sometimes at boot I get the following from the logs:
> >
> > ACPI: write EC, IB not empty
> > ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
> > [EmbeddedControl] [20060127]
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_.SMRD] (Node c13ecd40), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.UPBI]
> > (Node dbf42720), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.CHBP]
> > (Node dbf42660), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_.SMSL] (Node c13ecce0), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_._Q09] (Node c13ecc40), AE_TIME
> >
> > And after that the battery is reported as absent (even if it is physically
> > present). I get the impression that this happens when rebooting, not
> > from "cold powerons".
> >
> > This did not happen in 2.6.15, it appeared somewhere in 2.6.16-rc series.
> Could you post dmesgs of both, acpidump and .config? Could you bisect them?
>
And please Cc: linux-acpi@vger.kernel.org, thanks.
^ permalink raw reply
* RE: ACPI error in 2.6.16 (AE_TIME, Returned by Handler for EmbeddedControl)
From: Brown, Len @ 2006-03-23 1:45 UTC (permalink / raw)
To: Francesco Biscani, Linux Kernel Mailing List; +Cc: linux-acpi, Yu, Luming
>sometimes at boot I get the following from the logs:
>
>ACPI: write EC, IB not empty
>ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
>[EmbeddedControl] [20060127]
>ACPI Error (psparse-0517): Method parse/execution failed
>[\_SB_.PCI0.ISA_.EC0_.SMRD] (Node c13ecd40), AE_TIME
>ACPI Error (psparse-0517): Method parse/execution failed
>[\_SB_.BAT1.UPBI]
>(Node dbf42720), AE_TIME
>ACPI Error (psparse-0517): Method parse/execution failed
>[\_SB_.BAT1.CHBP]
>(Node dbf42660), AE_TIME
>ACPI Error (psparse-0517): Method parse/execution failed
>[\_SB_.PCI0.ISA_.EC0_.SMSL] (Node c13ecce0), AE_TIME
>ACPI Error (psparse-0517): Method parse/execution failed
>[\_SB_.PCI0.ISA_.EC0_._Q09] (Node c13ecc40), AE_TIME
>
>And after that the battery is reported as absent (even if it
>is physically
>present). I get the impression that this happens when rebooting, not
>from "cold powerons".
>
>This did not happen in 2.6.15, it appeared somewhere in
>2.6.16-rc series.
does this go away if you boot with "ec_intr=0"?
-Len
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-23 0:36 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060323000759.GB71469@muc.de>
On 23 Mar 2006 01:07:59 +0100
Andi Kleen <ak@muc.de> wrote:
> On Thu, Mar 23, 2006 at 08:27:32AM +0900, KAMEZAWA Hiroyuki wrote:
> > On 22 Mar 2006 20:21:34 +0100
> > Andi Kleen <ak@muc.de> wrote:
> >
> > > > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > > > also for x86_64, even if it's not NUMA.
> > >
> > > Hmm? x86_64 supports NUMA systems.
> > >
> > Ah, I know.
> > I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
>
> Hmm actually I haven't tested it but in theory the reserve hotplug
> code should just work if you list the new nodes already in SRAT as empty
> hotplug PXMs.
>
SRAT is required by Microsoft, then most of servers will equip it, I think.
And SRAT just tells each cpu's/memory range's a pxm.
But allocating memmap for SRAT entry has some problem in big system.
For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from
4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T memory.
(Microsoft requires "write all possible memory in SRAT")
When we reserve memmap for possible 1T memory, Linux will not work well in minimum 4G
configuraion ;)
So, I recommend allocate memmap dynamically.
> Ok there is no code yet to add hotplug cpus to specific nodes later
> but that would be easy to add.
>
We found hot-add-memory-less-node problem now. So, "cpu hot add to a new node"
will be supported later.
-- Kame
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-23 0:07 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060323082732.9828ca2f.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, Mar 23, 2006 at 08:27:32AM +0900, KAMEZAWA Hiroyuki wrote:
> On 22 Mar 2006 20:21:34 +0100
> Andi Kleen <ak@muc.de> wrote:
>
> > > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > > also for x86_64, even if it's not NUMA.
> >
> > Hmm? x86_64 supports NUMA systems.
> >
> Ah, I know.
> I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
Hmm actually I haven't tested it but in theory the reserve hotplug
code should just work if you list the new nodes already in SRAT as empty
hotplug PXMs.
Ok there is no code yet to add hotplug cpus to specific nodes later
but that would be easy to add.
The only problem is that mem_map has to be in another node so it will be
slightly slower.
-Andi
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-22 23:27 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060322192134.GA44212@muc.de>
On 22 Mar 2006 20:21:34 +0100
Andi Kleen <ak@muc.de> wrote:
> > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > also for x86_64, even if it's not NUMA.
>
> Hmm? x86_64 supports NUMA systems.
>
Ah, I know.
I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
-- Kame
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-22 19:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-acpi
In-Reply-To: <20060321222332.1a037c8e.akpm@osdl.org>
On Tue, Mar 21, 2006 at 10:23:32PM -0800, Andrew Morton wrote:
> WARNING: "remove_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "add_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "acpi_os_allocate" [drivers/acpi/acpi_memhotplug.ko] undefined!
>
> Does it actually make sense to load acpi_memhotplug.ko as a module? Will
> it all work?
>
Actually I found the real bug. All the places that check
for #ifdef CONFIG_ACPI_HOTPLUG_MEMORY need to check for
CONFIG_ACPI_HOTPLUG_MEMORY_MODULE (what a mouthful!) too.
-Andi
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-22 19:21 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Andrew Morton, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060322203220.6433e697.kamezawa.hiroyu@jp.fujitsu.com>
> It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> also for x86_64, even if it's not NUMA.
Hmm? x86_64 supports NUMA systems.
-Andi
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-22 17:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-acpi
In-Reply-To: <20060321222332.1a037c8e.akpm@osdl.org>
On Tue, Mar 21, 2006 at 10:23:32PM -0800, Andrew Morton wrote:
> WARNING: "remove_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "add_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "acpi_os_allocate" [drivers/acpi/acpi_memhotplug.ko] undefined!
>
> Does it actually make sense to load acpi_memhotplug.ko as a module? Will
Yes.
> it all work?
Just need to export the symbols I think. Thanks for the headsup.
-Andi
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-22 14:16 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B418018@pdsmsx403>
How about this. The side effect of this change is that _BIF, _BST could
NOT work. But I think it's just ok.
Method (I2RB, 3, NotSerialized)
{
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
/* Return (CHKS ())*/
}
It hangs in the usual way (2nd sleep). The boot messages had two Fatal
opcodes, but that must be the _BIF and _BST that you mentioned:
Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
ACPI: Fatal opcode executed
Execute Method: [\_TZ_.THM0._PSV] (Node e3f8be48)
Execute Method: [\_TZ_.THM0._TC1] (Node e3f8bdc8)
Execute Method: [\_TZ_.THM0._TC2] (Node e3f8bd88)
Execute Method: [\_TZ_.THM0._TSP] (Node e3f8bd48)
Execute Method: [\_TZ_.THM0._AC0] (Node e3f8bf48)
Execute Method: [\_TZ_.THM0._SCP] (Node e3f8bec8)
Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
ACPI: Fatal opcode executed
ACPI: Thermal Zone [THM0] (47 C)
With later modifications (e.g. commenting out one of the Store lines), I
could Return(0x00) instead of commenting out the line. Let me know
which ones to try.
One more thought. We know that commenting out the UPDT call in _TMP
fixes the hang. By bisecting the UPDT method, however, we change every
call to UPDT, including the one in THM0._TMP. So we're making extra
changes beyond what is needed to fix the hang (and maybe producing
another hang?).
But let's continue this bisection since it's almost done. If we
eventually find the offending statement, we can use the information in
order to find the smallest change that fixes the hang. We make a copy
of the original UPDT method, call it UPDTCOPY, say; same for I2RB. Then
THM0._TMP can call EC0.UPDTCOPY(), which calls I2RBCOPY. And we modify
I2RBCOPY, but we leave I2RB and UPDT alone.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-22 11:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: y-goto, ak, linux-acpi, tony.luck
In-Reply-To: <20060322030208.30e3581e.akpm@osdl.org>
On Wed, 22 Mar 2006 03:02:08 -0800
Andrew Morton <akpm@osdl.org> wrote:
> Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> I think the problem was introduced by one of the newly-queued patches in
> Andi's tree, possibly
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/patches/hotadd-reserve
>
I didn't notice this patch and am shocked now....
First, e820 doesn't holds information of memory which doesn't exist at boot
time, I think. This patch can work only with emulated environ.
Next, Goto-san is now working on new patches , node-hot-add.
It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
also for x86_64, even if it's not NUMA.
I doesn't think this patch should be merged *now*.
-- Kame
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andrew Morton @ 2006-03-22 11:02 UTC (permalink / raw)
To: Yasunori Goto; +Cc: ak, linux-acpi, tony.luck
In-Reply-To: <20060322192804.E490.Y-GOTO@jp.fujitsu.com>
Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
>
> > WARNING: "remove_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> > WARNING: "add_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> > WARNING: "acpi_os_allocate" [drivers/acpi/acpi_memhotplug.ko] undefined!
> >
> > Does it actually make sense to load acpi_memhotplug.ko as a module? Will
> > it all work?
>
> Are these warning 2.6.16-rc6-mm2?
> I tried it on ia64.
> If EXPORT_SYMBOL_GPL for them are defined, it worked well as a module.
> Probably, x86-64 will work by same definition.
>
> In 2.6.16 stock kernel, EXPORT_SYMBOL is already defined for
> add_memory() and remove_memory() of x86-64. (only x86-64, not for ia64).
> acpi_os_allocate() is not called in acpi_memhotplug.ko of 2.6.16.
> it is called only on 2.6-16-rc6-mm2.
>
I think the problem was introduced by one of the newly-queued patches in
Andi's tree, possibly
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/patches/hotadd-reserve
If acpi_memhotplug.ko works OK as a module then I guess adding the exports
is the right fix.
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Yasunori Goto @ 2006-03-22 10:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andi Kleen, linux-acpi, Luck, Tony
In-Reply-To: <20060321222332.1a037c8e.akpm@osdl.org>
> WARNING: "remove_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "add_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
> WARNING: "acpi_os_allocate" [drivers/acpi/acpi_memhotplug.ko] undefined!
>
> Does it actually make sense to load acpi_memhotplug.ko as a module? Will
> it all work?
Are these warning 2.6.16-rc6-mm2?
I tried it on ia64.
If EXPORT_SYMBOL_GPL for them are defined, it worked well as a module.
Probably, x86-64 will work by same definition.
In 2.6.16 stock kernel, EXPORT_SYMBOL is already defined for
add_memory() and remove_memory() of x86-64. (only x86-64, not for ia64).
acpi_os_allocate() is not called in acpi_memhotplug.ko of 2.6.16.
it is called only on 2.6-16-rc6-mm2.
Bye.
--
Yasunori Goto
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 7:28 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>Since I don't think Fatal() isn't being called, I guess the problem is
>in I2RB. But all those magic numbers in I2RB make me recultant to take
>out lines, unless you tell me which changes won't harm the hardware.
>
How about this. The side effect of this change is that _BIF, _BST could
NOT
work. But I think it's just ok.
Method (I2RB, 3, NotSerialized)
{
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
/* Return (CHKS ())*/
}
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-22 7:15 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417B9D@pdsmsx403>
So the kernel with this UPDT() hung at the 2nd sleep:
Method (UPDT, 0, NotSerialized)
{
If (IGNR)
{
Decrement (IGNR)
}
Else
{
If (H8DR)
{
If (Acquire (I2CM, 0x0064)) {}
Else
{
Store (I2RB (Zero, 0x01, 0x04), Local7)
If (Local7)
{
Fatal (0x01, 0x80000003, Local7)
}
Release (I2CM)
}
}
}
}
Relative to a working kernel (well, a kernel that I could get to hang
only once, and then all reboots afterwards it never would hang), these
are the extra lines:
Store (I2RB (Zero, 0x01, 0x04), Local7)
If (Local7)
{
Fatal (0x01, 0x80000003, Local7)
}
Since I don't think Fatal() isn't being called, I guess the problem is
in I2RB. But all those magic numbers in I2RB make me recultant to take
out lines, unless you tell me which changes won't harm the hardware.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-22 7:00 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417BB4@pdsmsx403>
I tried the following kernels (all with only THM0):
1. No other changes: It hangs, as before and as expected.
2. Commented out a large chunk of the UPDT() method:
diff -r ac2b38909dfa -r c431c477d3b6 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 17:12:47 2006 -0500
+++ b/dsdt/600x.dsl Wed Mar 22 00:22:21 2006 -0500
@@ -4132,19 +4132,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
If (Acquire (I2CM, 0x0064)) {}
Else
{
- Store (I2RB (Zero, 0x01, 0x04), Local7)
- If (Local7)
- {
- Fatal (0x01, 0x80000003, Local7)
- }
- Else
- {
- Store (HBS0, TMP0)
- Store (HBS2, TMP2)
- Store (HBS6, TMP6)
- Store (HBS7, TMP7)
- }
-
Release (I2CM)
}
}
So now it just grabs and releases the I2CM lock.
This kernel hung on the first sleep, but I couldn't reproduce that
behavior. I tried two more boots, and each time it never hung. I even
thought it might depend on the result of previous boots, so I tried
kernel #1 again and got the same hang, and then tried #2. But it still
wouldn't hang. So I went back through the serial console logs to check
whether I was hallucinating, and I was not. This kernel had indeed hung
on the first sleep, but only the first time I booted it.
So I'm going to assume that it's okay, and that if it isn't okay, it's
because of another, more intermitten bug.
3. Commented out EC0.UPDT() call in THM0._THM, and this kernel was fine,
which is how it behaved a couple days ago, and is what I expected.
I'm about to try a smaller change (continuing the bisect):
diff -r ac2b38909dfa -r f10a309b8385 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 17:12:47 2006 -0500
+++ b/dsdt/600x.dsl Wed Mar 22 01:44:12 2006 -0500
@@ -4137,13 +4137,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
{
Fatal (0x01, 0x80000003, Local7)
}
- Else
- {
- Store (HBS0, TMP0)
- Store (HBS2, TMP2)
- Store (HBS6, TMP6)
- Store (HBS7, TMP7)
- }
Release (I2CM)
}
After that bisection there's not much more to change in UPDT().
However, I can drill down into I2RB() because of this line in UPDT():
Store (I2RB (Zero, 0x01, 0x04), Local7)
But I have no idea what's safe to experiment with in I2RB():
Method (I2RB, 3, NotSerialized)
{
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
Return (CHKS ())
}
All those lines look like tricky hardware manipulations.
By the way, which debug_{level,layer} settings will show the lines of
the human-readable DSDT as they are executed?
-Sanjoy
^ permalink raw reply
* [patch 08/23] ACPI: Add "ACPI" to motherboard resources in /proc/io{mem,port}
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Add "ACPI" to motherboard resource allocation names, so people have a clue
about where to look. And remove some trailing spaces.
Changes these /proc/iomem entries from this:
ff5c1004-ff5c1007 : PM_TMR
ff5c1008-ff5c100b : PM1a_EVT_BLK
ff5c100c-ff5c100d : PM1a_CNT_BLK
ff5c1010-ff5c1013 : GPE0_BLK
ff5c1014-ff5c1017 : GPE1_BLK
to this:
ff5c1004-ff5c1007 : ACPI PM_TMR
ff5c1008-ff5c100b : ACPI PM1a_EVT_BLK
ff5c100c-ff5c100d : ACPI PM1a_CNT_BLK
ff5c1010-ff5c1013 : ACPI GPE0_BLK
ff5c1014-ff5c1017 : ACPI GPE1_BLK
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/motherboard.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff -puN drivers/acpi/motherboard.c~acpi-add-acpi-to-motherboard-resources-in-proc-iomemport drivers/acpi/motherboard.c
--- devel/drivers/acpi/motherboard.c~acpi-add-acpi-to-motherboard-resources-in-proc-iomemport 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/acpi/motherboard.c 2006-03-21 22:30:05.000000000 -0800
@@ -37,7 +37,7 @@ ACPI_MODULE_NAME("acpi_motherboard")
#define ACPI_MB_HID2 "PNP0C02"
/**
* Doesn't care about legacy IO ports, only IO ports beyond 0x1000 are reserved
- * Doesn't care about the failure of 'request_region', since other may reserve
+ * Doesn't care about the failure of 'request_region', since other may reserve
* the io ports as well
*/
#define IS_RESERVED_ADDR(base, len) \
@@ -46,7 +46,7 @@ ACPI_MODULE_NAME("acpi_motherboard")
/*
* Clearing the flag (IORESOURCE_BUSY) allows drivers to use
* the io ports if they really know they can use it, while
- * still preventing hotplug PCI devices from using it.
+ * still preventing hotplug PCI devices from using it.
*/
static acpi_status acpi_reserve_io_ranges(struct acpi_resource *res, void *data)
{
@@ -138,39 +138,39 @@ static void __init acpi_request_region (
static void __init acpi_reserve_resources(void)
{
acpi_request_region(&acpi_gbl_FADT->xpm1a_evt_blk,
- acpi_gbl_FADT->pm1_evt_len, "PM1a_EVT_BLK");
+ acpi_gbl_FADT->pm1_evt_len, "ACPI PM1a_EVT_BLK");
acpi_request_region(&acpi_gbl_FADT->xpm1b_evt_blk,
- acpi_gbl_FADT->pm1_evt_len, "PM1b_EVT_BLK");
+ acpi_gbl_FADT->pm1_evt_len, "ACPI PM1b_EVT_BLK");
acpi_request_region(&acpi_gbl_FADT->xpm1a_cnt_blk,
- acpi_gbl_FADT->pm1_cnt_len, "PM1a_CNT_BLK");
+ acpi_gbl_FADT->pm1_cnt_len, "ACPI PM1a_CNT_BLK");
acpi_request_region(&acpi_gbl_FADT->xpm1b_cnt_blk,
- acpi_gbl_FADT->pm1_cnt_len, "PM1b_CNT_BLK");
+ acpi_gbl_FADT->pm1_cnt_len, "ACPI PM1b_CNT_BLK");
if (acpi_gbl_FADT->pm_tm_len == 4)
- acpi_request_region(&acpi_gbl_FADT->xpm_tmr_blk, 4, "PM_TMR");
+ acpi_request_region(&acpi_gbl_FADT->xpm_tmr_blk, 4, "ACPI PM_TMR");
acpi_request_region(&acpi_gbl_FADT->xpm2_cnt_blk,
- acpi_gbl_FADT->pm2_cnt_len, "PM2_CNT_BLK");
+ acpi_gbl_FADT->pm2_cnt_len, "ACPI PM2_CNT_BLK");
/* Length of GPE blocks must be a non-negative multiple of 2 */
if (!(acpi_gbl_FADT->gpe0_blk_len & 0x1))
acpi_request_region(&acpi_gbl_FADT->xgpe0_blk,
- acpi_gbl_FADT->gpe0_blk_len, "GPE0_BLK");
+ acpi_gbl_FADT->gpe0_blk_len, "ACPI GPE0_BLK");
if (!(acpi_gbl_FADT->gpe1_blk_len & 0x1))
acpi_request_region(&acpi_gbl_FADT->xgpe1_blk,
- acpi_gbl_FADT->gpe1_blk_len, "GPE1_BLK");
+ acpi_gbl_FADT->gpe1_blk_len, "ACPI GPE1_BLK");
}
static int __init acpi_motherboard_init(void)
{
acpi_bus_register_driver(&acpi_motherboard_driver1);
acpi_bus_register_driver(&acpi_motherboard_driver2);
- /*
+ /*
* Guarantee motherboard IO reservation first
* This module must run after scan.c
*/
_
^ permalink raw reply
* [patch 07/23] ACPI: request correct fixed hardware resource type (MMIO vs I/O port)
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
ACPI supports fixed hardware (PM_TMR, GPE blocks, etc) in either I/O port
or MMIO space, but used to always request the regions from I/O space
because it didn't check the address_space_id.
Sample ACPI fixed hardware in MMIO space (HP rx2600), was incorrectly
reported in /proc/ioports, now reported in /proc/iomem:
ff5c1004-ff5c1007 : PM_TMR
ff5c1008-ff5c100b : PM1a_EVT_BLK
ff5c100c-ff5c100d : PM1a_CNT_BLK
ff5c1010-ff5c1013 : GPE0_BLK
ff5c1014-ff5c1017 : GPE1_BLK
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/motherboard.c | 41 +++++++++++++++++++----------------
1 files changed, 23 insertions(+), 18 deletions(-)
diff -puN drivers/acpi/motherboard.c~acpi-request-correct-fixed-hardware-resource-type-mmio-vs-i-o-port drivers/acpi/motherboard.c
--- devel/drivers/acpi/motherboard.c~acpi-request-correct-fixed-hardware-resource-type-mmio-vs-i-o-port 2006-03-21 22:30:04.000000000 -0800
+++ devel-akpm/drivers/acpi/motherboard.c 2006-03-21 22:30:04.000000000 -0800
@@ -123,41 +123,46 @@ static struct acpi_driver acpi_motherboa
},
};
+static void __init acpi_request_region (struct acpi_generic_address *addr,
+ unsigned int length, char *desc)
+{
+ if (!addr->address || !length)
+ return;
+
+ if (addr->address_space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+ request_region(addr->address, length, desc);
+ else if (addr->address_space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY)
+ request_mem_region(addr->address, length, desc);
+}
+
static void __init acpi_reserve_resources(void)
{
- if (acpi_gbl_FADT->xpm1a_evt_blk.address && acpi_gbl_FADT->pm1_evt_len)
- request_region(acpi_gbl_FADT->xpm1a_evt_blk.address,
+ acpi_request_region(&acpi_gbl_FADT->xpm1a_evt_blk,
acpi_gbl_FADT->pm1_evt_len, "PM1a_EVT_BLK");
- if (acpi_gbl_FADT->xpm1b_evt_blk.address && acpi_gbl_FADT->pm1_evt_len)
- request_region(acpi_gbl_FADT->xpm1b_evt_blk.address,
+ acpi_request_region(&acpi_gbl_FADT->xpm1b_evt_blk,
acpi_gbl_FADT->pm1_evt_len, "PM1b_EVT_BLK");
- if (acpi_gbl_FADT->xpm1a_cnt_blk.address && acpi_gbl_FADT->pm1_cnt_len)
- request_region(acpi_gbl_FADT->xpm1a_cnt_blk.address,
+ acpi_request_region(&acpi_gbl_FADT->xpm1a_cnt_blk,
acpi_gbl_FADT->pm1_cnt_len, "PM1a_CNT_BLK");
- if (acpi_gbl_FADT->xpm1b_cnt_blk.address && acpi_gbl_FADT->pm1_cnt_len)
- request_region(acpi_gbl_FADT->xpm1b_cnt_blk.address,
+ acpi_request_region(&acpi_gbl_FADT->xpm1b_cnt_blk,
acpi_gbl_FADT->pm1_cnt_len, "PM1b_CNT_BLK");
- if (acpi_gbl_FADT->xpm_tmr_blk.address && acpi_gbl_FADT->pm_tm_len == 4)
- request_region(acpi_gbl_FADT->xpm_tmr_blk.address, 4, "PM_TMR");
+ if (acpi_gbl_FADT->pm_tm_len == 4)
+ acpi_request_region(&acpi_gbl_FADT->xpm_tmr_blk, 4, "PM_TMR");
- if (acpi_gbl_FADT->xpm2_cnt_blk.address && acpi_gbl_FADT->pm2_cnt_len)
- request_region(acpi_gbl_FADT->xpm2_cnt_blk.address,
+ acpi_request_region(&acpi_gbl_FADT->xpm2_cnt_blk,
acpi_gbl_FADT->pm2_cnt_len, "PM2_CNT_BLK");
/* Length of GPE blocks must be a non-negative multiple of 2 */
- if (acpi_gbl_FADT->xgpe0_blk.address && acpi_gbl_FADT->gpe0_blk_len &&
- !(acpi_gbl_FADT->gpe0_blk_len & 0x1))
- request_region(acpi_gbl_FADT->xgpe0_blk.address,
+ if (!(acpi_gbl_FADT->gpe0_blk_len & 0x1))
+ acpi_request_region(&acpi_gbl_FADT->xgpe0_blk,
acpi_gbl_FADT->gpe0_blk_len, "GPE0_BLK");
- if (acpi_gbl_FADT->xgpe1_blk.address && acpi_gbl_FADT->gpe1_blk_len &&
- !(acpi_gbl_FADT->gpe1_blk_len & 0x1))
- request_region(acpi_gbl_FADT->xgpe1_blk.address,
+ if (!(acpi_gbl_FADT->gpe1_blk_len & 0x1))
+ acpi_request_region(&acpi_gbl_FADT->xgpe1_blk,
acpi_gbl_FADT->gpe1_blk_len, "GPE1_BLK");
}
_
^ permalink raw reply
* [patch 20/23] acpi signedness fix
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, ashok.raj, davej, kaneshige.kenji
From: Ashok Raj <ashok.raj@intel.com>
Local apic entries are only 8 bits, but it seemed to not be caught with u8
return value result in the check
cpu_index >= NR_CPUS becomming always false.
drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/processor_core.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/processor_core.c~acpi-signedness-fix-2 drivers/acpi/processor_core.c
--- devel/drivers/acpi/processor_core.c~acpi-signedness-fix-2 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/acpi/processor_core.c 2006-03-21 22:30:07.000000000 -0800
@@ -382,7 +382,7 @@ static int acpi_processor_remove_fs(stru
/* Use the acpiid in MADT to map cpus in case of SMP */
#ifndef CONFIG_SMP
-#define convert_acpiid_to_cpu(acpi_id) (0xff)
+#define convert_acpiid_to_cpu(acpi_id) (-1)
#else
#ifdef CONFIG_IA64
@@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
#define ARCH_BAD_APICID (0xff)
#endif
-static u8 convert_acpiid_to_cpu(u8 acpi_id)
+static int convert_acpiid_to_cpu(u8 acpi_id)
{
u16 apic_id;
int i;
@@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
acpi_status status = 0;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
- u8 cpu_index;
+ int cpu_index;
static int cpu0_initialized;
ACPI_FUNCTION_TRACE("acpi_processor_get_info");
@@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
- if (!cpu0_initialized && (cpu_index == 0xff) &&
+ if (!cpu0_initialized && (cpu_index == -1) &&
(num_online_cpus() == 1)) {
cpu_index = 0;
}
@@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
*/
- if (cpu_index >= NR_CPUS) {
+ if (cpu_index == -1) {
if (ACPI_FAILURE
(acpi_processor_hotadd_init(pr->handle, &pr->id))) {
ACPI_ERROR((AE_INFO,
_
^ permalink raw reply
* [patch 21/23] ACPI should depend on, not select PCI
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bunk
From: Adrian Bunk <bunk@stusta.de>
ACPI should depend on, not select PCI.
Otherwise, illegal configurations like X86_VOYAGER=y, PCI=y are
possible.
This patch also fixes the options select'ing ACPI to also select PCI.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ia64/Kconfig | 1 +
arch/x86_64/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +--
3 files changed, 3 insertions(+), 2 deletions(-)
diff -puN arch/ia64/Kconfig~acpi-should-depend-on-not-select-pci arch/ia64/Kconfig
--- devel/arch/ia64/Kconfig~acpi-should-depend-on-not-select-pci 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/arch/ia64/Kconfig 2006-03-21 22:30:07.000000000 -0800
@@ -69,6 +69,7 @@ choice
config IA64_GENERIC
bool "generic"
select ACPI
+ select PCI
select NUMA
select ACPI_NUMA
help
diff -puN arch/x86_64/Kconfig~acpi-should-depend-on-not-select-pci arch/x86_64/Kconfig
--- devel/arch/x86_64/Kconfig~acpi-should-depend-on-not-select-pci 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/arch/x86_64/Kconfig 2006-03-21 22:30:07.000000000 -0800
@@ -276,6 +276,7 @@ config X86_64_ACPI_NUMA
bool "ACPI NUMA detection"
depends on NUMA
select ACPI
+ select PCI
select ACPI_NUMA
default y
help
diff -puN drivers/acpi/Kconfig~acpi-should-depend-on-not-select-pci drivers/acpi/Kconfig
--- devel/drivers/acpi/Kconfig~acpi-should-depend-on-not-select-pci 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/acpi/Kconfig 2006-03-21 22:30:07.000000000 -0800
@@ -10,9 +10,8 @@ menu "ACPI (Advanced Configuration and P
config ACPI
bool "ACPI Support"
depends on IA64 || X86
+ depends on PCI
select PM
- select PCI
-
default y
---help---
Advanced Configuration and Power Interface (ACPI) support for
_
^ permalink raw reply
* [patch 19/23] serial: remove 8250_acpi (replaced by 8250_pnp and PNPACPI)
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas, ambx1, rmk
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
With the combination of PNPACPI and 8250_pnp, we no longer need 8250_acpi.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
dev/null | 183 --------------------------------------
drivers/serial/Kconfig | 8 -
drivers/serial/Makefile | 1
3 files changed, 192 deletions(-)
diff -L drivers/serial/8250_acpi.c -puN drivers/serial/8250_acpi.c~serial-remove-8250_acpi-replaced-by-8250_pnp-and-pnpacpi /dev/null
--- devel/drivers/serial/8250_acpi.c
+++ /dev/null 2003-09-15 06:40:47.000000000 -0700
@@ -1,183 +0,0 @@
-/*
- * Copyright (c) 2002-2003 Matthew Wilcox for Hewlett-Packard
- * Copyright (C) 2004 Hewlett-Packard Co
- * Bjorn Helgaas <bjorn.helgaas@hp.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/acpi.h>
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/serial_core.h>
-
-#include <acpi/acpi_bus.h>
-
-#include <asm/io.h>
-
-#include "8250.h"
-
-struct serial_private {
- int line;
-};
-
-static acpi_status acpi_serial_mmio(struct uart_port *port,
- struct acpi_resource_address64 *addr)
-{
- port->mapbase = addr->minimum;
- port->iotype = UPIO_MEM;
- port->flags |= UPF_IOREMAP;
- return AE_OK;
-}
-
-static acpi_status acpi_serial_port(struct uart_port *port,
- struct acpi_resource_io *io)
-{
- if (io->address_length) {
- port->iobase = io->minimum;
- port->iotype = UPIO_PORT;
- } else
- printk(KERN_ERR "%s: zero-length IO port range?\n", __FUNCTION__);
- return AE_OK;
-}
-
-static acpi_status acpi_serial_ext_irq(struct uart_port *port,
- struct acpi_resource_extended_irq *ext_irq)
-{
- int rc;
-
- if (ext_irq->interrupt_count > 0) {
- rc = acpi_register_gsi(ext_irq->interrupts[0],
- ext_irq->triggering, ext_irq->polarity);
- if (rc < 0)
- return AE_ERROR;
- port->irq = rc;
- }
- return AE_OK;
-}
-
-static acpi_status acpi_serial_irq(struct uart_port *port,
- struct acpi_resource_irq *irq)
-{
- int rc;
-
- if (irq->interrupt_count > 0) {
- rc = acpi_register_gsi(irq->interrupts[0],
- irq->triggering, irq->polarity);
- if (rc < 0)
- return AE_ERROR;
- port->irq = rc;
- }
- return AE_OK;
-}
-
-static acpi_status acpi_serial_resource(struct acpi_resource *res, void *data)
-{
- struct uart_port *port = (struct uart_port *) data;
- struct acpi_resource_address64 addr;
- acpi_status status;
-
- status = acpi_resource_to_address64(res, &addr);
- if (ACPI_SUCCESS(status))
- return acpi_serial_mmio(port, &addr);
- else if (res->type == ACPI_RESOURCE_TYPE_IO)
- return acpi_serial_port(port, &res->data.io);
- else if (res->type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ)
- return acpi_serial_ext_irq(port, &res->data.extended_irq);
- else if (res->type == ACPI_RESOURCE_TYPE_IRQ)
- return acpi_serial_irq(port, &res->data.irq);
- return AE_OK;
-}
-
-static int acpi_serial_add(struct acpi_device *device)
-{
- struct serial_private *priv;
- acpi_status status;
- struct uart_port port;
- int result;
-
- memset(&port, 0, sizeof(struct uart_port));
-
- port.uartclk = 1843200;
- port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
-
- priv = kmalloc(sizeof(struct serial_private), GFP_KERNEL);
- if (!priv) {
- result = -ENOMEM;
- goto fail;
- }
- memset(priv, 0, sizeof(*priv));
-
- status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- acpi_serial_resource, &port);
- if (ACPI_FAILURE(status)) {
- result = -ENODEV;
- goto fail;
- }
-
- if (!port.mapbase && !port.iobase) {
- printk(KERN_ERR "%s: no iomem or port address in %s _CRS\n",
- __FUNCTION__, device->pnp.bus_id);
- result = -ENODEV;
- goto fail;
- }
-
- priv->line = serial8250_register_port(&port);
- if (priv->line < 0) {
- printk(KERN_WARNING "Couldn't register serial port %s: %d\n",
- device->pnp.bus_id, priv->line);
- result = -ENODEV;
- goto fail;
- }
-
- acpi_driver_data(device) = priv;
- return 0;
-
-fail:
- kfree(priv);
-
- return result;
-}
-
-static int acpi_serial_remove(struct acpi_device *device, int type)
-{
- struct serial_private *priv;
-
- if (!device || !acpi_driver_data(device))
- return -EINVAL;
-
- priv = acpi_driver_data(device);
- serial8250_unregister_port(priv->line);
- kfree(priv);
-
- return 0;
-}
-
-static struct acpi_driver acpi_serial_driver = {
- .name = "serial",
- .class = "",
- .ids = "PNP0501",
- .ops = {
- .add = acpi_serial_add,
- .remove = acpi_serial_remove,
- },
-};
-
-static int __init acpi_serial_init(void)
-{
- return acpi_bus_register_driver(&acpi_serial_driver);
-}
-
-static void __exit acpi_serial_exit(void)
-{
- acpi_bus_unregister_driver(&acpi_serial_driver);
-}
-
-module_init(acpi_serial_init);
-module_exit(acpi_serial_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("Generic 8250/16x50 ACPI serial driver");
diff -puN drivers/serial/Kconfig~serial-remove-8250_acpi-replaced-by-8250_pnp-and-pnpacpi drivers/serial/Kconfig
--- devel/drivers/serial/Kconfig~serial-remove-8250_acpi-replaced-by-8250_pnp-and-pnpacpi 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/serial/Kconfig 2006-03-21 22:30:07.000000000 -0800
@@ -77,14 +77,6 @@ config SERIAL_8250_CS
If unsure, say N.
-config SERIAL_8250_ACPI
- bool "8250/16550 device discovery via ACPI namespace"
- default y if IA64
- depends on ACPI && SERIAL_8250
- ---help---
- If you wish to enable serial port discovery via the ACPI
- namespace, say Y here. If unsure, say N.
-
config SERIAL_8250_NR_UARTS
int "Maximum number of 8250/16550 serial ports"
depends on SERIAL_8250
diff -puN drivers/serial/Makefile~serial-remove-8250_acpi-replaced-by-8250_pnp-and-pnpacpi drivers/serial/Makefile
--- devel/drivers/serial/Makefile~serial-remove-8250_acpi-replaced-by-8250_pnp-and-pnpacpi 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/serial/Makefile 2006-03-21 22:30:07.000000000 -0800
@@ -5,7 +5,6 @@
#
serial-8250-y :=
-serial-8250-$(CONFIG_SERIAL_8250_ACPI) += 8250_acpi.o
serial-8250-$(CONFIG_PNP) += 8250_pnp.o
serial-8250-$(CONFIG_GSC) += 8250_gsc.o
serial-8250-$(CONFIG_PCI) += 8250_pci.o
_
^ permalink raw reply
* [patch 23/23] acpi memory hotplug cannot manage _CRS with plural resoureces
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, kamezawa.hiroyu, kaneshige.kenji
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Current acpi memory hotplug just looks into the first entry of resources in
_CRS. But, _CRS can contain plural resources. So, if _CRS contains plural
resoureces, acpi memory hot add cannot add all memory.
With this patch, acpi memory hotplug can deal with Memory Device, whose
_CRS contains plural resources.
Tested on ia64 memory hotplug test envrionment (not emulation, uses alpha
version firmware which supports dynamic reconfiguration of NUMA.)
Note: Microsoft's Windows Server 2003 requires big (>4G)resoureces to be
divided into small (<4G) resources. looks crazy, but not invalid.
(See http://www.microsoft.com/whdc/system/pnppwr/hotadd/hotaddmem.mspx)
For this reason, a firmware vendor who supports Windows writes plural
resources in a _CRS even if they are contiguous.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/acpi_memhotplug.c | 109 ++++++++++++++++++++++---------
1 files changed, 78 insertions(+), 31 deletions(-)
diff -puN drivers/acpi/acpi_memhotplug.c~acpi-memory-hotplug-cannot-manage-_crs-with-plural-resoureces drivers/acpi/acpi_memhotplug.c
--- devel/drivers/acpi/acpi_memhotplug.c~acpi-memory-hotplug-cannot-manage-_crs-with-plural-resoureces 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/acpi/acpi_memhotplug.c 2006-03-21 22:30:07.000000000 -0800
@@ -68,44 +68,76 @@ static struct acpi_driver acpi_memory_de
},
};
+struct acpi_memory_info {
+ struct list_head list;
+ u64 start_addr; /* Memory Range start physical addr */
+ u64 length; /* Memory Range length */
+ unsigned short caching; /* memory cache attribute */
+ unsigned short write_protect; /* memory read/write attribute */
+ unsigned int enabled:1;
+};
+
struct acpi_memory_device {
acpi_handle handle;
unsigned int state; /* State of the memory device */
- unsigned short caching; /* memory cache attribute */
- unsigned short write_protect; /* memory read/write attribute */
- u64 start_addr; /* Memory Range start physical addr */
- u64 length; /* Memory Range length */
+ struct list_head res_list;
};
+static acpi_status
+acpi_memory_get_resource(struct acpi_resource *resource, void *context)
+{
+ struct acpi_memory_device *mem_device = context;
+ struct acpi_resource_address64 address64;
+ struct acpi_memory_info *info, *new;
+ acpi_status status;
+
+ status = acpi_resource_to_address64(resource, &address64);
+ if (ACPI_FAILURE(status) ||
+ (address64.resource_type != ACPI_MEMORY_RANGE))
+ return AE_OK;
+
+ list_for_each_entry(info, &mem_device->res_list, list) {
+ /* Can we combine the resource range information? */
+ if ((info->caching == address64.info.mem.caching) &&
+ (info->write_protect == address64.info.mem.write_protect) &&
+ (info->start_addr + info->length == address64.minimum)) {
+ info->length += address64.address_length;
+ return AE_OK;
+ }
+ }
+
+ new = acpi_os_allocate(sizeof(struct acpi_memory_info));
+ if (!new)
+ return AE_ERROR;
+
+ memset(new, 0, sizeof(*new));
+ INIT_LIST_HEAD(&new->list);
+ new->caching = address64.info.mem.caching;
+ new->write_protect = address64.info.mem.write_protect;
+ new->start_addr = address64.minimum;
+ new->length = address64.address_length;
+ list_add_tail(&new->list, &mem_device->res_list);
+
+ return AE_OK;
+}
+
static int
acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
{
acpi_status status;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- struct acpi_resource *resource = NULL;
- struct acpi_resource_address64 address64;
+ struct acpi_memory_info *info, *n;
ACPI_FUNCTION_TRACE("acpi_memory_get_device_resources");
/* Get the range from the _CRS */
- status = acpi_get_current_resources(mem_device->handle, &buffer);
- if (ACPI_FAILURE(status))
+ status = acpi_walk_resources(mem_device->handle, METHOD_NAME__CRS,
+ acpi_memory_get_resource, mem_device);
+ if (ACPI_FAILURE(status)) {
+ list_for_each_entry_safe(info, n, &mem_device->res_list, list)
+ acpi_os_free(info);
return_VALUE(-EINVAL);
-
- resource = (struct acpi_resource *)buffer.pointer;
- status = acpi_resource_to_address64(resource, &address64);
- if (ACPI_SUCCESS(status)) {
- if (address64.resource_type == ACPI_MEMORY_RANGE) {
- /* Populate the structure */
- mem_device->caching = address64.info.mem.caching;
- mem_device->write_protect =
- address64.info.mem.write_protect;
- mem_device->start_addr = address64.minimum;
- mem_device->length = address64.address_length;
- }
}
- acpi_os_free(buffer.pointer);
return_VALUE(0);
}
@@ -180,7 +212,8 @@ static int acpi_memory_check_device(stru
static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
{
- int result;
+ int result, num_enabled = 0;
+ struct acpi_memory_info *info;
ACPI_FUNCTION_TRACE("acpi_memory_enable_device");
@@ -195,12 +228,21 @@ static int acpi_memory_enable_device(str
/*
* Tell the VM there is more memory here...
* Note: Assume that this function returns zero on success
+ * We don't have memory-hot-add rollback function,now.
+ * (i.e. memory-hot-remove function)
*/
- result = add_memory(mem_device->start_addr, mem_device->length);
- if (result) {
+ list_for_each_entry(info, &mem_device->res_list, list) {
+ result = add_memory(info->start_addr, info->length);
+ if (result)
+ continue;
+ info->enabled = 1;
+ num_enabled++;
+ }
+
+ if (!num_enabled) {
ACPI_ERROR((AE_INFO, "add_memory failed"));
mem_device->state = MEMORY_INVALID_STATE;
- return result;
+ return -EINVAL;
}
return result;
@@ -244,8 +286,7 @@ static int acpi_memory_powerdown_device(
static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
{
int result;
- u64 start = mem_device->start_addr;
- u64 len = mem_device->length;
+ struct acpi_memory_info *info, *n;
ACPI_FUNCTION_TRACE("acpi_memory_disable_device");
@@ -253,9 +294,14 @@ static int acpi_memory_disable_device(st
* Ask the VM to offline this memory range.
* Note: Assume that this function returns zero on success
*/
- result = remove_memory(start, len);
- if (result)
- return_VALUE(result);
+ list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
+ if (info->enabled) {
+ result = remove_memory(info->start_addr, info->length);
+ if (result)
+ return_VALUE(result);
+ }
+ acpi_os_free(info);
+ }
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
@@ -347,6 +393,7 @@ static int acpi_memory_device_add(struct
return_VALUE(-ENOMEM);
memset(mem_device, 0, sizeof(struct acpi_memory_device));
+ INIT_LIST_HEAD(&mem_device->res_list);
mem_device->handle = device->handle;
sprintf(acpi_device_name(device), "%s", ACPI_MEMORY_DEVICE_NAME);
sprintf(acpi_device_class(device), "%s", ACPI_MEMORY_DEVICE_CLASS);
_
^ permalink raw reply
* [patch 22/23] acpi EC: acpi-ecdt-uid-hack
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, jirislaby, luming.yu
From: Jiri Slaby <jirislaby@gmail.com>
On some boxes ecdt uid may be equal to 0, so do not test for uids equality,
so that fake handler will be unconditionally removed to allow loading the
real one.
See http://bugzilla.kernel.org/show_bug.cgi?id=6111
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Luming Yu <luming.yu@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/ec.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff -puN drivers/acpi/ec.c~acpi-ec-acpi-ecdt-uid-hack drivers/acpi/ec.c
--- devel/drivers/acpi/ec.c~acpi-ec-acpi-ecdt-uid-hack 2006-03-21 22:30:07.000000000 -0800
+++ devel-akpm/drivers/acpi/ec.c 2006-03-21 22:30:07.000000000 -0800
@@ -989,7 +989,6 @@ static int acpi_ec_poll_add(struct acpi_
int result = 0;
acpi_status status = AE_OK;
union acpi_ec *ec = NULL;
- unsigned long uid;
ACPI_FUNCTION_TRACE("acpi_ec_add");
@@ -1012,10 +1011,9 @@ static int acpi_ec_poll_add(struct acpi_
acpi_evaluate_integer(ec->common.handle, "_GLK", NULL,
&ec->common.global_lock);
- /* If our UID matches the UID for the ECDT-enumerated EC,
- we now have the *real* EC info, so kill the makeshift one. */
- acpi_evaluate_integer(ec->common.handle, "_UID", NULL, &uid);
- if (ec_ecdt && ec_ecdt->common.uid == uid) {
+ /* XXX we don't test uids, because on some boxes ecdt uid = 0, see:
+ http://bugzilla.kernel.org/show_bug.cgi?id=6111 */
+ if (ec_ecdt) {
acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
ACPI_ADR_SPACE_EC,
&acpi_ec_space_handler);
@@ -1059,7 +1057,6 @@ static int acpi_ec_intr_add(struct acpi_
int result = 0;
acpi_status status = AE_OK;
union acpi_ec *ec = NULL;
- unsigned long uid;
ACPI_FUNCTION_TRACE("acpi_ec_add");
@@ -1085,10 +1082,9 @@ static int acpi_ec_intr_add(struct acpi_
acpi_evaluate_integer(ec->common.handle, "_GLK", NULL,
&ec->common.global_lock);
- /* If our UID matches the UID for the ECDT-enumerated EC,
- we now have the *real* EC info, so kill the makeshift one. */
- acpi_evaluate_integer(ec->common.handle, "_UID", NULL, &uid);
- if (ec_ecdt && ec_ecdt->common.uid == uid) {
+ /* XXX we don't test uids, because on some boxes ecdt uid = 0, see:
+ http://bugzilla.kernel.org/show_bug.cgi?id=6111 */
+ if (ec_ecdt) {
acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
ACPI_ADR_SPACE_EC,
&acpi_ec_space_handler);
_
^ permalink raw reply
* [patch 16/23] acpi_os_acquire_object (GFP_KERNEL) called with IRQs disabled through suspend-resume
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, davi.arnaut, pavel
From: Davi Arnaut <davi.arnaut@gmail.com>
acpi_os_acquire_object() gets called, with IRQs disabled, from:
Debug: sleeping function called from invalid context at mm/slab.c:2499
in_atomic():0, irqs_disabled():1
[<c01462f3>] kmem_cache_alloc+0x40/0x4f [<c0202c85>] acpi_os_acquire_object+0xb/0x3c
[<c02171b1>] acpi_ut_allocate_object_desc_dbg+0x13/0x49 [<c021704b>] acpi_ut_create_internal_object_dbg+0xf/0x5e
[<c02136d4>] acpi_rs_set_srs_method_data+0x3d/0xb9 [<c021aa3d>] acpi_pci_link_set+0x102/0x17b
[<c021aecb>] irqrouter_resume+0x1e/0x3c [<c024d921>] __sysdev_resume+0x11/0x6b
[<c024dbde>] sysdev_resume+0x34/0x52 [<c0251cb7>] device_power_up+0x5/0xa
[<c0138787>] suspend_enter+0x44/0x46 [<c01386e5>] suspend_prepare+0x63/0xc1
[<c0138813>] enter_state+0x5e/0x7c [<c013894c>] state_store+0x81/0x8f
[<c01388cb>] state_store+0x0/0x8f [<c0196a0a>] subsys_attr_store+0x1e/0x22
[<c0196c12>] flush_write_buffer+0x22/0x28 [<c0196c64>] sysfs_write_file+0x4c/0x71
[<c0196c18>] sysfs_write_file+0x0/0x71 [<c015b2c9>] vfs_write+0xa2/0x15a
[<c015b42c>] sys_write+0x41/0x6a [<c0102e75>] syscall_call+0x7/0xb
The patch also fixes a missing check for NULL return from
acpi_os_acquire_object().
Signed-off-by: Davi Arnaut <davi.arnaut@gmail.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/osl.c | 7 ++++++-
drivers/acpi/parser/psutils.c | 8 ++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff -puN drivers/acpi/osl.c~acpi_os_acquire_object-gfp_kernel-called-with-irqs drivers/acpi/osl.c
--- devel/drivers/acpi/osl.c~acpi_os_acquire_object-gfp_kernel-called-with-irqs 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/osl.c 2006-03-21 22:30:06.000000000 -0800
@@ -1175,7 +1175,12 @@ acpi_status acpi_os_release_object(acpi_
void *acpi_os_acquire_object(acpi_cache_t * cache)
{
- void *object = kmem_cache_alloc(cache, GFP_KERNEL);
+ void *object;
+
+ if (acpi_in_resume)
+ object = kmem_cache_alloc(cache, GFP_ATOMIC);
+ else
+ object = kmem_cache_alloc(cache, GFP_KERNEL);
WARN_ON(!object);
return object;
}
diff -puN drivers/acpi/parser/psutils.c~acpi_os_acquire_object-gfp_kernel-called-with-irqs drivers/acpi/parser/psutils.c
--- devel/drivers/acpi/parser/psutils.c~acpi_os_acquire_object-gfp_kernel-called-with-irqs 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/parser/psutils.c 2006-03-21 22:30:06.000000000 -0800
@@ -139,12 +139,16 @@ union acpi_parse_object *acpi_ps_alloc_o
/* The generic op (default) is by far the most common (16 to 1) */
op = acpi_os_acquire_object(acpi_gbl_ps_node_cache);
- memset(op, 0, sizeof(struct acpi_parse_obj_common));
+
+ if (op)
+ memset(op, 0, sizeof(struct acpi_parse_obj_common));
} else {
/* Extended parseop */
op = acpi_os_acquire_object(acpi_gbl_ps_node_ext_cache);
- memset(op, 0, sizeof(struct acpi_parse_obj_named));
+
+ if (op)
+ memset(op, 0, sizeof(struct acpi_parse_obj_named));
}
/* Initialize the Op */
_
^ permalink raw reply
* [patch 17/23] acpi: ia64: wake on LAN fix
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, takeuchi_satoru, tony.luck
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Currently wakeup capability is available if and only if
CONFIG_ACPI_SLEEP=y. But S5 is not a sleep state. This patch makes ACPI
subsystem to be able to wakeup from S5 state even if sleep mode is not
supported.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/sleep/Makefile | 3 +--
drivers/acpi/sleep/poweroff.c | 1 +
drivers/acpi/sleep/proc.c | 16 ++++++++++++++++
drivers/acpi/sleep/wakeup.c | 2 ++
4 files changed, 20 insertions(+), 2 deletions(-)
diff -puN drivers/acpi/sleep/Makefile~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/Makefile
--- devel/drivers/acpi/sleep/Makefile~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/Makefile 2006-03-21 22:30:06.000000000 -0800
@@ -1,5 +1,4 @@
-obj-y := poweroff.o wakeup.o
+obj-y := poweroff.o wakeup.o proc.o
obj-$(CONFIG_ACPI_SLEEP) += main.o
-obj-$(CONFIG_ACPI_SLEEP_PROC_FS) += proc.o
EXTRA_CFLAGS += $(ACPI_CFLAGS)
diff -puN drivers/acpi/sleep/poweroff.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/poweroff.c
--- devel/drivers/acpi/sleep/poweroff.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/poweroff.c 2006-03-21 22:30:06.000000000 -0800
@@ -45,6 +45,7 @@ void acpi_power_off(void)
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
printk("%s called\n", __FUNCTION__);
local_irq_disable();
+ acpi_enable_wakeup_device(ACPI_STATE_S5);
/* Some SMP machines only can poweroff in boot CPU */
acpi_enter_sleep_state(ACPI_STATE_S5);
}
diff -puN drivers/acpi/sleep/proc.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/proc.c
--- devel/drivers/acpi/sleep/proc.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/proc.c 2006-03-21 22:30:06.000000000 -0800
@@ -70,6 +70,7 @@ acpi_system_write_sleep(struct file *fil
}
#endif /* CONFIG_ACPI_SLEEP_PROC_SLEEP */
+#ifdef CONFIG_ACPI_SLEEP
static int acpi_system_alarm_seq_show(struct seq_file *seq, void *offset)
{
u32 sec, min, hr;
@@ -339,6 +340,7 @@ acpi_system_write_alarm(struct file *fil
end:
return_VALUE(result ? result : count);
}
+#endif /* CONFIG_ACPI_SLEEP */
extern struct list_head acpi_wakeup_device_list;
extern spinlock_t acpi_device_lock;
@@ -357,6 +359,10 @@ acpi_system_wakeup_device_seq_show(struc
if (!dev->wakeup.flags.valid)
continue;
+#ifndef CONFIG_ACPI_SLEEP
+ if (dev->wakeup.sleep_state != ACPI_STATE_S5)
+ continue;
+#endif
spin_unlock(&acpi_device_lock);
seq_printf(seq, "%4s %4d %s%8s\n",
dev->pnp.bus_id,
@@ -394,6 +400,10 @@ acpi_system_write_wakeup_device(struct f
container_of(node, struct acpi_device, wakeup_list);
if (!dev->wakeup.flags.valid)
continue;
+#ifndef CONFIG_ACPI_SLEEP
+ if (dev->wakeup.sleep_state != ACPI_STATE_S5)
+ continue;
+#endif
if (!strncmp(dev->pnp.bus_id, str, 4)) {
dev->wakeup.state.enabled =
@@ -452,6 +462,7 @@ static struct file_operations acpi_syste
};
#endif /* CONFIG_ACPI_SLEEP_PROC_SLEEP */
+#ifdef CONFIG_ACPI_SLEEP
static struct file_operations acpi_system_alarm_fops = {
.open = acpi_system_alarm_open_fs,
.read = seq_read,
@@ -467,6 +478,7 @@ static u32 rtc_handler(void *context)
return ACPI_INTERRUPT_HANDLED;
}
+#endif /* CONFIG_ACPI_SLEEP */
static int acpi_sleep_proc_init(void)
{
@@ -484,12 +496,14 @@ static int acpi_sleep_proc_init(void)
entry->proc_fops = &acpi_system_sleep_fops;
#endif
+#ifdef CONFIG_ACPI_SLEEP
/* 'alarm' [R/W] */
entry =
create_proc_entry("alarm", S_IFREG | S_IRUGO | S_IWUSR,
acpi_root_dir);
if (entry)
entry->proc_fops = &acpi_system_alarm_fops;
+#endif
/* 'wakeup device' [R/W] */
entry =
@@ -498,7 +512,9 @@ static int acpi_sleep_proc_init(void)
if (entry)
entry->proc_fops = &acpi_system_wakeup_device_fops;
+#ifdef CONFIG_ACPI_SLEEP
acpi_install_fixed_event_handler(ACPI_EVENT_RTC, rtc_handler, NULL);
+#endif
return 0;
}
diff -puN drivers/acpi/sleep/wakeup.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/wakeup.c
--- devel/drivers/acpi/sleep/wakeup.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/wakeup.c 2006-03-21 22:30:06.000000000 -0800
@@ -48,6 +48,7 @@ void acpi_enable_wakeup_device_prep(u8 s
}
spin_unlock(&acpi_device_lock);
}
+#endif
/**
* acpi_enable_wakeup_device - enable wakeup devices
@@ -100,6 +101,7 @@ void acpi_enable_wakeup_device(u8 sleep_
spin_unlock(&acpi_device_lock);
}
+#ifdef CONFIG_ACPI_SLEEP
/**
* acpi_disable_wakeup_device - disable devices' wakeup capability
* @sleep_state: ACPI state
_
^ permalink raw reply
* [patch 18/23] ACPI: remove __init/__exit from Asus .add()/.remove() methods
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Even though the devices claimed by asus_acpi.c can not be hot-plugged, the
driver registration infrastructure allows the .add() and .remove() methods to
be called at any time while the driver is registered. So remove __init and
__exit from them.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/asus_acpi.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/asus_acpi.c~acpi-remove-__init-__exit-from-asus-add-remove-methods drivers/acpi/asus_acpi.c
--- devel/drivers/acpi/asus_acpi.c~acpi-remove-__init-__exit-from-asus-add-remove-methods 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/asus_acpi.c 2006-03-21 22:30:06.000000000 -0800
@@ -817,7 +817,7 @@ typedef int (proc_writefunc) (struct fil
unsigned long count, void *data);
static int
-__init asus_proc_add(char *name, proc_writefunc * writefunc,
+asus_proc_add(char *name, proc_writefunc * writefunc,
proc_readfunc * readfunc, mode_t mode,
struct acpi_device *device)
{
@@ -836,7 +836,7 @@ __init asus_proc_add(char *name, proc_wr
return 0;
}
-static int __init asus_hotk_add_fs(struct acpi_device *device)
+static int asus_hotk_add_fs(struct acpi_device *device)
{
struct proc_dir_entry *proc;
mode_t mode;
@@ -954,7 +954,7 @@ static void asus_hotk_notify(acpi_handle
* This function is used to initialize the hotk with right values. In this
* method, we can make all the detection we want, and modify the hotk struct
*/
-static int __init asus_hotk_get_info(void)
+static int asus_hotk_get_info(void)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_buffer dsdt = { ACPI_ALLOCATE_BUFFER, NULL };
@@ -1101,7 +1101,7 @@ static int __init asus_hotk_get_info(voi
return AE_OK;
}
-static int __init asus_hotk_check(void)
+static int asus_hotk_check(void)
{
int result = 0;
@@ -1121,7 +1121,7 @@ static int __init asus_hotk_check(void)
static int asus_hotk_found;
-static int __init asus_hotk_add(struct acpi_device *device)
+static int asus_hotk_add(struct acpi_device *device)
{
acpi_status status = AE_OK;
int result;
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox