[PATCH 1/5] Trivial whitespace cleanups

[PATCH 1/5] Trivial whitespace cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 arch/x86/include/asm/string_32.h |    1 -
 arch/x86/kernel/tsc.c            |    2 +-
 drivers/acpi/acpica/tbfadt.c     |    1 -
 3 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/string_32.h b/arch/x86/include/asm/string_32.h
index c86f452..ae907e6 100644
--- a/arch/x86/include/asm/string_32.h
+++ b/arch/x86/include/asm/string_32.h
@@ -65,7 +65,6 @@ static __always_inline void *__constant_memcpy(void *to, const void *from,
 	case 4:
 		*(int *)to = *(int *)from;
 		return to;
-
 	case 3:
 		*(short *)to = *(short *)from;
 		*((char *)to + 2) = *((char *)from + 2);
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 71f4368..8a2fc11 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -670,7 +670,7 @@ static int time_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
 	if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
 			(val == CPUFREQ_POSTCHANGE && freq->old > freq->new) ||
 			(val == CPUFREQ_RESUMECHANGE)) {
-		*lpj = 	cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
+		*lpj = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
 
 		tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
 		if (!(freq->flags & CPUFREQ_CONST_LOOPS))
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 82b02dc..c016335 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -275,7 +275,6 @@ void acpi_tb_parse_fadt(u32 table_index)
 
 void acpi_tb_create_local_fadt(struct acpi_table_header *table, u32 length)
 {
-
 	/*
 	 * Check if the FADT is larger than the largest table that we expect
 	 * (the ACPI 2.0/3.0 version). If so, truncate the table, and issue
-- 
1.6.5.rc1

[PATCH 4/5] acpi: fix trivial warning

[Felipe Contreras]

drivers/acpi/acpica/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 include/acpi/actypes.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 37ba576..e312be7 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -438,8 +438,8 @@ typedef unsigned long long acpi_integer;
 
 #define ACPI_SET_BIT(target,bit)        ((target) |= (bit))
 #define ACPI_CLEAR_BIT(target,bit)      ((target) &= ~(bit))
-#define ACPI_MIN(a,b)                   (((a)<(b))?(a):(b))
-#define ACPI_MAX(a,b)                   (((a)>(b))?(a):(b))
+#define ACPI_MIN(a,b)                   min(a, b)
+#define ACPI_MAX(a,b)                   max(a, b)
 
 /* Size calculation */
 
-- 
1.6.5.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] acpi: fix trivial warnings caused by previous commmit

[Felipe Contreras]

drivers/acpi/acpica/exfldio.c: In function ‘acpi_ex_extract_from_field’:
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:761: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:780: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c: In function ‘acpi_ex_insert_into_field’:
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:880: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast
drivers/acpi/acpica/exfldio.c:933: warning: comparison of distinct pointer types lacks a cast

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 drivers/acpi/acpica/exfldio.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index 6687be1..4affc5f 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -760,7 +760,7 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
 
 		ACPI_MEMCPY(((char *)buffer) + buffer_offset, &merged_datum,
 			    ACPI_MIN(obj_desc->common_field.access_byte_width,
-				     buffer_length - buffer_offset));
+				     (u8)(buffer_length - buffer_offset)));
 
 		buffer_offset += obj_desc->common_field.access_byte_width;
 		merged_datum =
@@ -779,7 +779,7 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
 
 	ACPI_MEMCPY(((char *)buffer) + buffer_offset, &merged_datum,
 		    ACPI_MIN(obj_desc->common_field.access_byte_width,
-			     buffer_length - buffer_offset));
+			     (u8)(buffer_length - buffer_offset)));
 
 	return_ACPI_STATUS(AE_OK);
 }
@@ -879,7 +879,7 @@ acpi_ex_insert_into_field(union acpi_operand_object *obj_desc,
 
 	ACPI_MEMCPY(&raw_datum, buffer,
 		    ACPI_MIN(obj_desc->common_field.access_byte_width,
-			     buffer_length - buffer_offset));
+			     (u8)(buffer_length - buffer_offset)));
 
 	merged_datum =
 	    raw_datum << obj_desc->common_field.start_field_bit_offset;
@@ -932,7 +932,7 @@ acpi_ex_insert_into_field(union acpi_operand_object *obj_desc,
 		buffer_offset += obj_desc->common_field.access_byte_width;
 		ACPI_MEMCPY(&raw_datum, ((char *)buffer) + buffer_offset,
 			    ACPI_MIN(obj_desc->common_field.access_byte_width,
-				     buffer_length - buffer_offset));
+				     (u8)(buffer_length - buffer_offset)));
 		merged_datum |=
 		    raw_datum << obj_desc->common_field.start_field_bit_offset;
 	}
-- 
1.6.5.rc1

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Sun, 2009-09-13 at 22:38 +0300, Felipe Contreras wrote:
> drivers/acpi/acpica/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
> arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>

Could you run this through checkpatch also, it looks like you have a few
style issues..

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] acpi: fix trivial warning

[Felipe Contreras]

On Mon, Sep 14, 2009 at 4:55 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Sun, 2009-09-13 at 22:38 +0300, Felipe Contreras wrote:
>> drivers/acpi/acpica/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
>> arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>
> Could you run this through checkpatch also, it looks like you have a few
> style issues..

I did... the style issues are already there, my patch is not
introducing them. Do you want me to send a separate patch to fix the
existing style issues?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
> On Mon, Sep 14, 2009 at 4:55 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Sun, 2009-09-13 at 22:38 +0300, Felipe Contreras wrote:
> >> drivers/acpi/acpica/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
> >> arch/x86/include/asm/string_32.h:74: warning: array subscript is above array bounds
> >>
> >> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> >
> > Could you run this through checkpatch also, it looks like you have a few
> > style issues..
> 
> I did... the style issues are already there, my patch is not
> introducing them. Do you want me to send a separate patch to fix the
> existing style issues?

Yes, If your inclined to clean up the whole file, or just the
surrounding code that would be helpful ..

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] acpi: fix trivial warning

[Felipe Contreras]

On Mon, Sep 14, 2009 at 5:02 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
>> I did... the style issues are already there, my patch is not
>> introducing them. Do you want me to send a separate patch to fix the
>> existing style issues?
>
> Yes, If your inclined to clean up the whole file, or just the
> surrounding code that would be helpful ..

Nobody seems to like the patch you suggested me to do... did I wasted
my time doing it?
http://article.gmane.org/gmane.linux.acpi.devel/42383

-- 
Felipe Contreras

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Thu, 2009-11-12 at 02:23 +0200, Felipe Contreras wrote:
> On Mon, Sep 14, 2009 at 5:02 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
> >> I did... the style issues are already there, my patch is not
> >> introducing them. Do you want me to send a separate patch to fix the
> >> existing style issues?
> >
> > Yes, If your inclined to clean up the whole file, or just the
> > surrounding code that would be helpful ..
> 
> Nobody seems to like the patch you suggested me to do... did I wasted
> my time doing it?
> http://article.gmane.org/gmane.linux.acpi.devel/42383

Did you get some negative feedback ? I don't see any..

Daniel

Re: [PATCH 4/5] acpi: fix trivial warning

[Felipe Contreras]

On Fri, Nov 13, 2009 at 7:43 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Thu, 2009-11-12 at 02:23 +0200, Felipe Contreras wrote:
>> On Mon, Sep 14, 2009 at 5:02 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>> > On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
>> >> I did... the style issues are already there, my patch is not
>> >> introducing them. Do you want me to send a separate patch to fix the
>> >> existing style issues?
>> >
>> > Yes, If your inclined to clean up the whole file, or just the
>> > surrounding code that would be helpful ..
>>
>> Nobody seems to like the patch you suggested me to do... did I wasted
>> my time doing it?
>> http://article.gmane.org/gmane.linux.acpi.devel/42383
>
> Did you get some negative feedback ? I don't see any..

Well:
---
And after today's discussion on kernel summit on this topic, I wouldn't
expect any maintainer to merge it, sorry :)
---

That doesn't seem too positive. Or at least there's no indication that
somebody will pick it up.

-- 
Felipe Contreras

Re: [PATCH 4/5] acpi: fix trivial warning

[Thiago Farina]

On Fri, Nov 13, 2009 at 6:28 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Nov 13, 2009 at 7:43 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>> On Thu, 2009-11-12 at 02:23 +0200, Felipe Contreras wrote:
>>> On Mon, Sep 14, 2009 at 5:02 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>>> > On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
>>> >> I did... the style issues are already there, my patch is not
>>> >> introducing them. Do you want me to send a separate patch to fix the
>>> >> existing style issues?
>>> >
>>> > Yes, If your inclined to clean up the whole file, or just the
>>> > surrounding code that would be helpful ..
>>>
>>> Nobody seems to like the patch you suggested me to do... did I wasted
>>> my time doing it?
>>> http://article.gmane.org/gmane.linux.acpi.devel/42383
>>
>> Did you get some negative feedback ? I don't see any..
>
> Well:
> ---
> And after today's discussion on kernel summit on this topic, I wouldn't
> expect any maintainer to merge it, sorry :)
> ---
>
> That doesn't seem too positive. Or at least there's no indication that
> somebody will pick it up.

I think it is because it doesn't "aggregate" real value to the kernel
(like fixing a crash, that adds value), and the other guys has more
things to do, and don't have time to waste. But that can not be the
true, this is just my point of view.

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Fri, 2009-11-13 at 22:28 +0200, Felipe Contreras wrote:
> On Fri, Nov 13, 2009 at 7:43 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Thu, 2009-11-12 at 02:23 +0200, Felipe Contreras wrote:
> >> On Mon, Sep 14, 2009 at 5:02 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> >> > On Mon, 2009-09-14 at 17:34 +0300, Felipe Contreras wrote:
> >> >> I did... the style issues are already there, my patch is not
> >> >> introducing them. Do you want me to send a separate patch to fix the
> >> >> existing style issues?
> >> >
> >> > Yes, If your inclined to clean up the whole file, or just the
> >> > surrounding code that would be helpful ..
> >>
> >> Nobody seems to like the patch you suggested me to do... did I wasted
> >> my time doing it?
> >> http://article.gmane.org/gmane.linux.acpi.devel/42383
> >
> > Did you get some negative feedback ? I don't see any..
> 
> Well:
> ---
> And after today's discussion on kernel summit on this topic, I wouldn't
> expect any maintainer to merge it, sorry :)
> ---
> 
> That doesn't seem too positive. Or at least there's no indication that
> somebody will pick it up.


I'd re-submit with a better description of the patch. You should always
try to describe what your doing as accurately as possible so the
maintainer doesn't have to work very hard to know what your doing.. That
particular patch just has a one liner description that wasn't very
informative .. Either that or re-submit your series without that patch
if you don't have confidence in it.

Daniel

Re: [PATCH 4/5] acpi: fix trivial warning

[Felipe Contreras]

On Sun, Nov 15, 2009 at 7:15 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> On Fri, 2009-11-13 at 22:28 +0200, Felipe Contreras wrote:
>> That doesn't seem too positive. Or at least there's no indication that
>> somebody will pick it up.
>
> I'd re-submit with a better description of the patch. You should always
> try to describe what your doing as accurately as possible so the
> maintainer doesn't have to work very hard to know what your doing.

There's nothing to add. It's a patch to cleanup the coding style, that's it.

> That
> particular patch just has a one liner description that wasn't very
> informative .. Either that or re-submit your series without that patch
> if you don't have confidence in it.

All of my patches have been picked up, except the ones for ACPI. I
haven't received a single comment from them, which would explain the
current state of the code.

If somebody raised the hand and said; I'll merge this, please resend,
I'd do that, otherwise I think it's a waste of time.

-- 
Felipe Contreras

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Sun, 2009-11-15 at 19:27 +0200, Felipe Contreras wrote:
> On Sun, Nov 15, 2009 at 7:15 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Fri, 2009-11-13 at 22:28 +0200, Felipe Contreras wrote:
> >> That doesn't seem too positive. Or at least there's no indication that
> >> somebody will pick it up.
> >
> > I'd re-submit with a better description of the patch. You should always
> > try to describe what your doing as accurately as possible so the
> > maintainer doesn't have to work very hard to know what your doing.
> 
> There's nothing to add. It's a patch to cleanup the coding style, that's it.

How do you know the coding style isn't correct? Did you just visually
inspect it?

> > That
> > particular patch just has a one liner description that wasn't very
> > informative .. Either that or re-submit your series without that patch
> > if you don't have confidence in it.
> 
> All of my patches have been picked up, except the ones for ACPI. I
> haven't received a single comment from them, which would explain the
> current state of the code.
> 
> If somebody raised the hand and said; I'll merge this, please resend,
> I'd do that, otherwise I think it's a waste of time.

Patches often times aren't accepted in the first submission, could be
for lots of reasons. It's your series tho ..

Daniel

Re: [PATCH 4/5] acpi: fix trivial warning

[Alexey Starikovskiy]

You've made changes to automatically generated files, so all the style 
changes
would be overwritten when next time these files are generated -- all the 
files go through
Lindent, and almost all your changes were introduced by it. If you 
really want to make
style changes to ACPICA files, try to play with Lindent, so it produce 
what you want.
If you have anything beside style patches, please submit them separately

Regards,
Alex.

Daniel Walker wrote:
> On Sun, 2009-11-15 at 19:27 +0200, Felipe Contreras wrote:
>   
>> On Sun, Nov 15, 2009 at 7:15 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>>     
>>> On Fri, 2009-11-13 at 22:28 +0200, Felipe Contreras wrote:
>>>       
>>>> That doesn't seem too positive. Or at least there's no indication that
>>>> somebody will pick it up.
>>>>         
>>> I'd re-submit with a better description of the patch. You should always
>>> try to describe what your doing as accurately as possible so the
>>> maintainer doesn't have to work very hard to know what your doing.
>>>       
>> There's nothing to add. It's a patch to cleanup the coding style, that's it.
>>     
>
> How do you know the coding style isn't correct? Did you just visually
> inspect it?
>
>   
>>> That
>>> particular patch just has a one liner description that wasn't very
>>> informative .. Either that or re-submit your series without that patch
>>> if you don't have confidence in it.
>>>       
>> All of my patches have been picked up, except the ones for ACPI. I
>> haven't received a single comment from them, which would explain the
>> current state of the code.
>>
>> If somebody raised the hand and said; I'll merge this, please resend,
>> I'd do that, otherwise I think it's a waste of time.
>>     
>
> Patches often times aren't accepted in the first submission, could be
> for lots of reasons. It's your series tho ..
>
> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Sun, 2009-11-15 at 20:54 +0300, Alexey Starikovskiy wrote:
> You've made changes to automatically generated files, so all the style 
> changes
> would be overwritten when next time these files are generated -- all the 
> files go through
> Lindent, and almost all your changes were introduced by it. If you 
> really want to make
> style changes to ACPICA files, try to play with Lindent, so it produce 
> what you want.
> If you have anything beside style patches, please submit them separately
> 

AFAIK, Lindent can't produce checkpatch clean output. It has to do with
various short comings in indent. You really need a human to check up on
it.

Daniel

Re: [PATCH 4/5] acpi: fix trivial warning

[Daniel Walker]

On Sun, 2009-11-15 at 21:10 +0300, Alexey Starikovskiy wrote:

> >   
> It is not really possible. Lindent is not the last step in the process.

What are the steps on the process?

Daniel

Re: [PATCH 4/5] acpi: fix trivial warning

[Alexey Starikovskiy]

Daniel Walker wrote:
> On Sun, 2009-11-15 at 20:54 +0300, Alexey Starikovskiy wrote:
>   
>> You've made changes to automatically generated files, so all the style 
>> changes
>> would be overwritten when next time these files are generated -- all the 
>> files go through
>> Lindent, and almost all your changes were introduced by it. If you 
>> really want to make
>> style changes to ACPICA files, try to play with Lindent, so it produce 
>> what you want.
>> If you have anything beside style patches, please submit them separately
>>
>>     
>
> AFAIK, Lindent can't produce checkpatch clean output. It has to do with
> various short comings in indent. You really need a human to check up on
> it.
>
> Daniel
>
>   
It is not really possible. Lindent is not the last step in the process.

Re: [PATCH 4/5] acpi: fix trivial warning

[Lin Ming]

On Mon, 2009-11-16 at 01:27 +0800, Felipe Contreras wrote:
> On Sun, Nov 15, 2009 at 7:15 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> > On Fri, 2009-11-13 at 22:28 +0200, Felipe Contreras wrote:
> >> That doesn't seem too positive. Or at least there's no indication that
> >> somebody will pick it up.
> >
> > I'd re-submit with a better description of the patch. You should always
> > try to describe what your doing as accurately as possible so the
> > maintainer doesn't have to work very hard to know what your doing.
> 
> There's nothing to add. It's a patch to cleanup the coding style, that's it.
> 
> > That
> > particular patch just has a one liner description that wasn't very
> > informative .. Either that or re-submit your series without that patch
> > if you don't have confidence in it.
> 
> All of my patches have been picked up, except the ones for ACPI. I
> haven't received a single comment from them, which would explain the
> current state of the code.

Hi, Felipe

All files under linux-2.6/drivers/acpi/acpica and most files under
linux-2.6/include/acpi are ACPICA code, see http://www.acpica.org for
detail.

The ACPICA's coding style is totally different than linux kernel.
For example, a function named AcpiEvaluateObject in ACPICA, but in linux
kernel it is called acpi_evaluate_object.

We have a program "acpisrc" to convert the ACPICA style code to linux
style and then run lindent on the converted code.

You can download the official ACPICA release from
http://www.acpica.org/downloads/ , "acpisrc" is included in it.

It's great that you are contributing to ACPICA code.
All these linuxized ACPICA codes are generated by acpisrc and lindent,
so we'd better not touch those code directly.

Instead, our process is:
1. Write patches for ACPICA code.
2. Send patches to devel.acpica.org, robert.moore@intel.com, ming.m.lin@intel.com
3. I will generate and send the linuxized ACPICA code to Len Brown <lenb@kernel.org>
4. Len asks Linus to merge the linuxized ACPICA code.

Thanks,
Lin Ming

> 
> If somebody raised the hand and said; I'll merge this, please resend,
> I'd do that, otherwise I think it's a waste of time.
>