Re: [git pull request] ACPI patches for 2.6.36.merge

Re: [git pull request] ACPI patches for 2.6.36.merge

[Sedat Dilek]

I pulled in release GIT-branch on top of 2.6.35-git16 (commit
5d7cb157025b3b4852f38e6e5e97d06ef12c1d78)

   $ git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
release

Unfortunately, the build breaks:

[ build.log ]
drivers/acpi/power.c: In function ‘acpi_power_off_device’:
drivers/acpi/power.c:252: error: ‘ref’ undeclared (first use in this function)
drivers/acpi/power.c:252: error: (Each undeclared identifier is
reported only once
drivers/acpi/power.c:252: error: for each function it appears in.)
make[5]: *** [drivers/acpi/power.o] Error 1
make[4]: *** [drivers/acpi] Error 2
make[3]: *** [drivers] Error 2


- Sedat -

Re: [git pull request] ACPI patches for 2.6.36.merge

[Sedat Dilek]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Sun, Aug 15, 2010 at 12:41 PM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> I pulled in release GIT-branch on top of 2.6.35-git16 (commit
> 5d7cb157025b3b4852f38e6e5e97d06ef12c1d78)
>
>   $ git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> release
>
> Unfortunately, the build breaks:
>
> [ build.log ]
> drivers/acpi/power.c: In function ‘acpi_power_off_device’:
> drivers/acpi/power.c:252: error: ‘ref’ undeclared (first use in this function)
> drivers/acpi/power.c:252: error: (Each undeclared identifier is
> reported only once
> drivers/acpi/power.c:252: error: for each function it appears in.)
> make[5]: *** [drivers/acpi/power.o] Error 1
> make[4]: *** [drivers/acpi] Error 2
> make[3]: *** [drivers] Error 2
>

Attached patch is fixing the issue here.

- Sedat -

[-- Attachment #2: ACPI-Fix-undeclared-ref-in-acpi_power_off_device.patch --]
[-- Type: text/x-diff, Size: 430 bytes --]

diff -rdup linux-2.6.orig/drivers/acpi/power.c linux-2.6/drivers/acpi/power.c
--- linux-2.6.orig/drivers/acpi/power.c
+++ linux-2.6/drivers/acpi/power.c
@@ -242,6 +242,7 @@ static int acpi_power_off_device(acpi_ha
 	acpi_status status = AE_OK;
 	struct acpi_power_resource *resource = NULL;
 	struct list_head *node, *next;
+	struct acpi_power_reference *ref;
 
 	result = acpi_power_get_context(handle, &resource);
 	if (result)

Re: [git pull request] ACPI patches for 2.6.36.merge

[Linus Torvalds]

On Sun, Aug 15, 2010 at 3:41 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> I pulled in release GIT-branch on top of 2.6.35-git16 (commit
> 5d7cb157025b3b4852f38e6e5e97d06ef12c1d78)
>
>   $ git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> release
>
> Unfortunately, the build breaks:
>
> [ build.log ]
> drivers/acpi/power.c: In function ‘acpi_power_off_device’:
> drivers/acpi/power.c:252: error: ‘ref’ undeclared (first use in this function)

What the heck is going on? That thing cannot have been tested AT ALL.
It comes from commit cfa806f05980 ("gcc-4.6: ACPI: fix unused but set
variables in ACPI"), and there is no way that code has ever been
compiled. There's no conditional compilation (except for not enabling
ACPI at all), and the declaration of 'ref' that the commit removes is
followed just a few lines later by the use.

So WTF?

I can merge this and fix it up, but I'm not going to. This thing
should never have been sent to me. It clearly had no testing at all. I
even looked at whether it could _possibly_ be some kind of odd "patch
applied with fuzz at the wrong place" issue, but that looks impossible
too (not to mention _still_ not being an excuse for not even trying to
compile the thing).

I understand when people don't notice compile errors that don't happen
for them (due to being architecture- or configuration-specific), but I
really don't see how that could _ever_ have been the case here.

I see Andrew in the sign-off chain, which surprises me. Maybe he just
passed on the patch blindly. But seriously, what the _hell_ is going
on here?

                              Linus

Re: [git pull request] ACPI patches for 2.6.36.merge

[Andrew Morton]

On Sun, 15 Aug 2010 11:15:51 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Aug 15, 2010 at 3:41 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> > I pulled in release GIT-branch on top of 2.6.35-git16 (commit
> > 5d7cb157025b3b4852f38e6e5e97d06ef12c1d78)
> >
> >   $ git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> > release
> >
> > Unfortunately, the build breaks:
> >
> > [ build.log ]
> > drivers/acpi/power.c: In function ‘acpi_power_off_device’:
> > drivers/acpi/power.c:252: error: ‘ref’ undeclared (first use in this function)
> 
> What the heck is going on? That thing cannot have been tested AT ALL.
> It comes from commit cfa806f05980 ("gcc-4.6: ACPI: fix unused but set
> variables in ACPI"), and there is no way that code has ever been
> compiled. There's no conditional compilation (except for not enabling
> ACPI at all), and the declaration of 'ref' that the commit removes is
> followed just a few lines later by the use.
> 
> So WTF?
> 
> I can merge this and fix it up, but I'm not going to. This thing
> should never have been sent to me. It clearly had no testing at all. I
> even looked at whether it could _possibly_ be some kind of odd "patch
> applied with fuzz at the wrong place" issue, but that looks impossible
> too (not to mention _still_ not being an excuse for not even trying to
> compile the thing).
> 
> I understand when people don't notice compile errors that don't happen
> for them (due to being architecture- or configuration-specific), but I
> really don't see how that could _ever_ have been the case here.
> 
> I see Andrew in the sign-off chain, which surprises me. Maybe he just
> passed on the patch blindly. But seriously, what the _hell_ is going
> on here?
> 

I'd be suspecting that we have two patches both of which worked
separately but which broke when combined.  Is there some other patch in
that tree which adds a new reference to `ref' in acpi_power_seq_show()?
--
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: [git pull request] ACPI patches for 2.6.36.merge

[Andrew Morton]

On Sun, 15 Aug 2010 11:15:51 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Aug 15, 2010 at 3:41 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> > I pulled in release GIT-branch on top of 2.6.35-git16 (commit
> > 5d7cb157025b3b4852f38e6e5e97d06ef12c1d78)
> >
> >   $ git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> > release
> >
> > Unfortunately, the build breaks:
> >
> > [ build.log ]
> > drivers/acpi/power.c: In function ‘acpi_power_off_device’:
> > drivers/acpi/power.c:252: error: ‘ref’ undeclared (first use in this function)
> 
> What the heck is going on? That thing cannot have been tested AT ALL.
> It comes from commit cfa806f05980 ("gcc-4.6: ACPI: fix unused but set
> variables in ACPI"), and there is no way that code has ever been
> compiled. There's no conditional compilation (except for not enabling
> ACPI at all), and the declaration of 'ref' that the commit removes is
> followed just a few lines later by the use.
> 
> So WTF?
> 
> I can merge this and fix it up, but I'm not going to. This thing
> should never have been sent to me. It clearly had no testing at all. I
> even looked at whether it could _possibly_ be some kind of odd "patch
> applied with fuzz at the wrong place" issue, but that looks impossible
> too (not to mention _still_ not being an excuse for not even trying to
> compile the thing).
> 
> I understand when people don't notice compile errors that don't happen
> for them (due to being architecture- or configuration-specific), but I
> really don't see how that could _ever_ have been the case here.
> 
> I see Andrew in the sign-off chain, which surprises me. Maybe he just
> passed on the patch blindly. But seriously, what the _hell_ is going
> on here?
> 

I'd be suspecting that we have two patches both of which worked
separately but which broke when combined.  Is there some other patch in
that tree which adds a new reference to `ref' in acpi_power_seq_show()?

Re: [git pull request] ACPI patches for 2.6.36.merge

[Linus Torvalds]

On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> I'd be suspecting that we have two patches both of which worked
> separately but which broke when combined.  Is there some other patch in
> that tree which adds a new reference to `ref' in acpi_power_seq_show()?

The offending patch isn't about acpi_power_seq_show(), it's about
acpi_power_off_device().

But that may well explain the breakage: there does seem to be an
unused ref in acpi_power_seq_show() (around line 556). It's just that
the patch in question doesn't remove that one, it removes the
very-much-used one in acpi_power_off_device() (line 256 or so).

And the contexts don't even match. Well, they do match to 2 lines. But
they're not very close. However, Len's tree does have a patch to just
remove all the procfs crap, so acpi_power_seq_show() has gone away,
which I guess explains how the subsequent patch was then applied to
something it should never have been applied to. Probably with GNU
patch that doesn't mind the fact that it doesn't match exactly (or
somebody used git and explicitly said "apply it with fuzz").

So that seems to explain how the patch got corrupted.

But nothing explains the fact that clearly _zero_ testing was done.
The tree was clearly never even compiled. Len apparently did a blind
patch application (or rebase, or whatever), and never bothered to
compile the end result afterwards, just sent it to me sight-unseen.

What does that say about the _rest_ of the patches? What does that say
about (lack of) -next testing?

                         Linus
--
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: [git pull request] ACPI patches for 2.6.36.merge

[Linus Torvalds]

On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> I'd be suspecting that we have two patches both of which worked
> separately but which broke when combined.  Is there some other patch in
> that tree which adds a new reference to `ref' in acpi_power_seq_show()?

The offending patch isn't about acpi_power_seq_show(), it's about
acpi_power_off_device().

But that may well explain the breakage: there does seem to be an
unused ref in acpi_power_seq_show() (around line 556). It's just that
the patch in question doesn't remove that one, it removes the
very-much-used one in acpi_power_off_device() (line 256 or so).

And the contexts don't even match. Well, they do match to 2 lines. But
they're not very close. However, Len's tree does have a patch to just
remove all the procfs crap, so acpi_power_seq_show() has gone away,
which I guess explains how the subsequent patch was then applied to
something it should never have been applied to. Probably with GNU
patch that doesn't mind the fact that it doesn't match exactly (or
somebody used git and explicitly said "apply it with fuzz").

So that seems to explain how the patch got corrupted.

But nothing explains the fact that clearly _zero_ testing was done.
The tree was clearly never even compiled. Len apparently did a blind
patch application (or rebase, or whatever), and never bothered to
compile the end result afterwards, just sent it to me sight-unseen.

What does that say about the _rest_ of the patches? What does that say
about (lack of) -next testing?

                         Linus

Re: [git pull request] ACPI patches for 2.6.36.merge

[Andrew Morton]

On Sun, 15 Aug 2010 14:04:09 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > I'd be suspecting that we have two patches both of which worked
> > separately but which broke when combined.  Is there some other patch in
> > that tree which adds a new reference to `ref' in acpi_power_seq_show()?
> 
> The offending patch isn't about acpi_power_seq_show(), it's about
> acpi_power_off_device().

The patch I sent Len patched acpi_power_seq_show().

> 
> ...
>
> What does that say about the _rest_ of the patches?

Not tested in combination?

> What does that say about (lack of) -next testing?

That code compiled OK in -mm which includes linux-next.  I assume that
some last-minute merging broke things.

--
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: [git pull request] ACPI patches for 2.6.36.merge

[Andrew Morton]

On Sun, 15 Aug 2010 14:04:09 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > I'd be suspecting that we have two patches both of which worked
> > separately but which broke when combined.  Is there some other patch in
> > that tree which adds a new reference to `ref' in acpi_power_seq_show()?
> 
> The offending patch isn't about acpi_power_seq_show(), it's about
> acpi_power_off_device().

The patch I sent Len patched acpi_power_seq_show().

> 
> ...
>
> What does that say about the _rest_ of the patches?

Not tested in combination?

> What does that say about (lack of) -next testing?

That code compiled OK in -mm which includes linux-next.  I assume that
some last-minute merging broke things.

Re: [git pull request] ACPI patches for 2.6.36.merge

[Linus Torvalds]

On Sun, Aug 15, 2010 at 6:21 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> The patch I sent Len patched acpi_power_seq_show().
>
>> What does that say about the _rest_ of the patches?
>
> Not tested in combination?

Not tested at all. They were apparently just applied from some other
source. And not even safely, but with "they can apply with fuzz",
which is downright dangerous. And then the result saw neither a
compiler nor a boot.

>> What does that say about (lack of) -next testing?
>
> That code compiled OK in -mm which includes linux-next.  I assume that
> some last-minute merging broke things.

There are _zero_ merge errors there. Go take a look at Len's tree.
It's a linear progression of patches AND THE PATCH IN LEN'S TREE IS
BUGGY.

It's that simple. It clearly never ever saw -next, because it _cannot_
have seen next. That particular commit can never have compiled.

Now, if you sent a patch that touched acpi_power_seq_show(), then the
error happened at Len's side. He took a patch, applied it with fuzz at
the wrong place, and sent the result to me without ever even compiling
it. And that doesn't make me happy.

I decided I should probably pull anyway, because at least the reason
for the bug was explained. And I want to get -rc1 out today. But I'm
grumbling, and judging from your emails, you didn't even look at what
Len sent me. There really are _no_ excuses.

                       Linus
--
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: [git pull request] ACPI patches for 2.6.36.merge

[Linus Torvalds]

On Sun, Aug 15, 2010 at 6:21 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> The patch I sent Len patched acpi_power_seq_show().
>
>> What does that say about the _rest_ of the patches?
>
> Not tested in combination?

Not tested at all. They were apparently just applied from some other
source. And not even safely, but with "they can apply with fuzz",
which is downright dangerous. And then the result saw neither a
compiler nor a boot.

>> What does that say about (lack of) -next testing?
>
> That code compiled OK in -mm which includes linux-next.  I assume that
> some last-minute merging broke things.

There are _zero_ merge errors there. Go take a look at Len's tree.
It's a linear progression of patches AND THE PATCH IN LEN'S TREE IS
BUGGY.

It's that simple. It clearly never ever saw -next, because it _cannot_
have seen next. That particular commit can never have compiled.

Now, if you sent a patch that touched acpi_power_seq_show(), then the
error happened at Len's side. He took a patch, applied it with fuzz at
the wrong place, and sent the result to me without ever even compiling
it. And that doesn't make me happy.

I decided I should probably pull anyway, because at least the reason
for the bug was explained. And I want to get -rc1 out today. But I'm
grumbling, and judging from your emails, you didn't even look at what
Len sent me. There really are _no_ excuses.

                       Linus

Re: [git pull request] ACPI patches for 2.6.36.merge

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Sun, 15 Aug 2010 18:35:22 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> It's that simple. It clearly never ever saw -next, because it _cannot_
> have seen next. That particular commit can never have compiled.

Yeah, it turned up in Len's tree that I fetch over the weekend.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [git pull request] ACPI patches for 2.6.36.merge

[Len Brown]

My bad.

Andrew was right -- I botched a modify/delete
merge conflict of two correct patches.
I did it at the last minute and then fed the wrong branch
("idle-release" instead of "release") to my build test,
send the code, and dropped of the net.  multiple mistakes.

Sorry for the sloppiness, I'll do better.

Upon the git merge conflict, it looks like I resorted to
pulling andi's original patch out of git, pushing it into
quilt on top of rui's delete; and then got fooled
by the refresh.  Should have caught that both by inspection
and by build...

On a positive note, the underlying reason for the conflict
was that we are succeeding in deleting a bunch of crufty code
that should not need to be maintained at all:-)

thanks,
Len Brown, Intel Open Source Technology Center

[git pull request] ACPI patches for 2.6.36.merge

[Len Brown]

Hi Linus,

please pull from: 

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

This will update the files shown below.

thanks!

--
Len Brown
Intel Open Source Technology Center


ps. individual patches are available on linux-acpi@vger.kernel.org
and a consolidated plain patch is available here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/2.6.35/acpi-release-20100702-2.6.35.diff.gz

 Documentation/acpi/method-customizing.txt |    2 +
 arch/x86/kernel/cpu/mcheck/mce-apei.c     |    4 +-
 drivers/acpi/Kconfig                      |   11 +-
 drivers/acpi/Makefile                     |    5 +-
 drivers/acpi/acpica/acevents.h            |    4 +
 drivers/acpi/acpica/acglobal.h            |    2 +-
 drivers/acpi/acpica/aclocal.h             |    1 +
 drivers/acpi/acpica/evgpe.c               |   73 +++++
 drivers/acpi/acpica/evxface.c             |   77 ++++--
 drivers/acpi/acpica/evxfevnt.c            |   62 +----
 drivers/acpi/acpica/utmutex.c             |    5 +-
 drivers/acpi/apei/Kconfig                 |    9 +
 drivers/acpi/apei/Makefile                |    1 +
 drivers/acpi/apei/apei-base.c             |    4 +-
 drivers/acpi/apei/erst-dbg.c              |  207 +++++++++++++
 drivers/acpi/apei/ghes.c                  |  172 ++++++-----
 drivers/acpi/apei/hest.c                  |   76 +++++-
 drivers/acpi/bus.c                        |    4 +-
 drivers/acpi/debug.c                      |  422 --------------------------
 drivers/acpi/debugfs.c                    |   93 ++++++
 drivers/acpi/glue.c                       |    3 +-
 drivers/acpi/internal.h                   |    8 +-
 drivers/acpi/numa.c                       |    4 +-
 drivers/acpi/osl.c                        |    7 +-
 drivers/acpi/power.c                      |  130 +--------
 drivers/acpi/proc.c                       |   70 -----
 drivers/acpi/processor_driver.c           |   85 ------
 drivers/acpi/processor_idle.c             |  102 +-------
 drivers/acpi/processor_thermal.c          |   83 -----
 drivers/acpi/processor_throttling.c       |    2 -
 drivers/acpi/sleep.c                      |   60 ++---
 drivers/acpi/sleep.h                      |    5 +-
 drivers/acpi/{system.c => sysfs.c}        |  466 ++++++++++++++++-------------
 drivers/acpi/thermal.c                    |   86 ++++--
 drivers/acpi/video.c                      |  141 ++++++----
 drivers/acpi/wakeup.c                     |   48 +---
 drivers/ata/libata-acpi.c                 |    6 -
 include/acpi/acpixf.h                     |    2 +-
 include/acpi/processor.h                  |    1 -
 include/linux/cper.h                      |    8 +-
 40 files changed, 1071 insertions(+), 1480 deletions(-)
 create mode 100644 drivers/acpi/apei/erst-dbg.c
 delete mode 100644 drivers/acpi/debug.c
 create mode 100644 drivers/acpi/debugfs.c
 rename drivers/acpi/{system.c => sysfs.c} (57%)

through these commits:

Andi Kleen (1):
      gcc-4.6: ACPI: fix unused but set variables in ACPI

Huang Ying (4):
      ACPI, APEI, Fix a typo of error path of apei_resources_request
      ACPI, APEI, Rename CPER and GHES severity constants
      ACPI, APEI, Manage GHES as platform devices
      ACPI, APEI, ERST debug support

Rafael J. Wysocki (6):
      ACPI / Sleep: Free NVS copy if suspending of devices fails
      ACPI / Sleep: Rework enabling wakeup devices
      ACPI / Wakeup: Simplify enabling of wakeup devices
      ACPI / Sleep: Consolidate suspend and hibernation routines
      ACPI / Sleep: Drop acpi_suspend_finish()
      ACPI / ACPICA: Fix reference counting problems with GPE handlers

Zhang Rui (8):
      ACPI: introduce drivers/acpi/debugfs.c
      ACPI: introduce module parameter acpi.aml_debug_output
      ACPI: introduce drivers/acpi/sysfs.c
      ACPI: remove deprecated ACPI procfs I/F
      ACPI power_resource: remove unused procfs I/F
      ACPI processor: remove deprecated ACPI procfs I/F
      ACPI video: make procfs I/F depend on CONFIG_ACPI_PROCFS
      ACPI thermal: make procfs I/F depend on CONFIG_ACPI_PROCFS

Zhao Yakui (1):
      ACPI: Add the check of ADR flag in course of finding ACPI handle for PCI device

with this log:

commit 95ee46aa8698f2000647dfb362400fadbb5807cf
Merge: cfa806f 92fa5bd9
Author: Len Brown <len.brown@intel.com>
Date:   Sun Aug 15 01:06:31 2010 -0400

    Merge branch 'linus' into release
    
    Conflicts:
    	drivers/acpi/debug.c
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit cfa806f059801dbe7e435745eb2e187c8bfe1e7f
Author: Andi Kleen <andi@firstfloor.org>
Date:   Tue Jul 20 15:18:36 2010 -0700

    gcc-4.6: ACPI: fix unused but set variables in ACPI
    
    Some minor improvements in error handling, but overall it was mostly dead
    code.
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 43d9f87b79804f2d75d9d8a81c862b179f055a15
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:44 2010 +0800

    ACPI thermal: make procfs I/F depend on CONFIG_ACPI_PROCFS
    
    Mark the ACPI thermal procfs I/F deprecated, because /sys/class/thermal/
    is already available and has been working for years w/o any problem.
    
    The ACPI thermal procfs I/F will be removed in 2.6.37.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 6e37c658aefa57c472b2dbf1de88dbd3c67cdb52
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:43 2010 +0800

    ACPI video: make procfs I/F depend on CONFIG_ACPI_PROCFS
    
    Mark ACPI video driver procfs I/F deprecated, including:
    /proc/acpi/video/*/info
    /proc/acpi/video/*/DOS
    /proc/acpi/video/*/ROM
    /proc/acpi/video/*/POST
    /proc/acpi/video/*/POST_info
    /proc/acpi/video/*/*/info
    /proc/acpi/video/*/*/state
    /proc/acpi/video/*/*/EDID
    and
    /proc/acpi/video/*/*/brightness, because
    1. we already have the sysfs I/F /sysclass/backlight/ as the replacement
    of /proc/acpi/video/*/*/brightness.
    2. the other procfs I/F is not useful for userspace.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit d09fe55510257f1acd21ea80a9bdd7c72b5895b3
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:41 2010 +0800

    ACPI processor: remove deprecated ACPI procfs I/F
    
    Remove deprecated ACPI processor procfs I/F, including:
    /proc/acpi/processor/CPUX/power
    /proc/acpi/processor/CPUX/limit
    /proc/acpi/processor/CPUX/info
    
    /proc/acpi/processor/CPUX/throttling still exists,
    as we don't have sysfs I/F available for now.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 06af7eb043c02822072cea862fce1b7c74115e8f
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:38 2010 +0800

    ACPI power_resource: remove unused procfs I/F
    
    Remove unused ACPI power procfs I/F.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 47f5c892b06797336a34f1096b4b617623aa1960
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:33 2010 +0800

    ACPI: remove deprecated ACPI procfs I/F
    
    Rmove deprecated ACPI procfs I/F, including
    /proc/acpi/debug_layer
    /proc/acpi/debug_level
    /proc/acpi/info
    /proc/acpi/dsdt
    /proc/acpi/fadt
    /proc/acpi/sleep
    
    because the sysfs I/F is already available
    and has been working well for years.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 1c8fce27e275fd7c6b75bc6455745f02d3903ee6
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:30 2010 +0800

    ACPI: introduce drivers/acpi/sysfs.c
    
    Introduce drivers/acpi/sysfs.c.
    
    code for ACPI sysfs I/F, including
    #ifdef ACPI_DEBUG
    /sys/module/acpi/parameters/debug_layer
    /sys/module/acpi/parameters/debug_level
    /sys/module/acpi/parameters/trace_method_name
    /sys/module/acpi/parameters/trace_debug_layer
    /sys/module/acpi/parameters/trace_debug_level
    /sys/module/acpi/parameters/trace_state
    #endif
    /sys/module/acpi/parameters/acpica_version
    /sys/firmware/acpi/tables/
    /sys/firmware/acpi/interrupts/
    is moved to this file.
    
    No function change in this patch.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit c172cb73bc79fe69915b1a1a48e374aa4b1f8a59
Merge: e8eb622 28f4f8a
Author: Len Brown <len.brown@intel.com>
Date:   Sun Aug 15 00:25:40 2010 -0400

    Merge branch 'acpica-gpe' into release

commit e8eb6228094bcf0c84d9aa32b6363e78da68e1f5
Merge: ecd8ee0 108029f
Author: Len Brown <len.brown@intel.com>
Date:   Sat Aug 14 23:57:32 2010 -0400

    Merge branch 'bugzilla-16422' into release

commit ecd8ee0955a2f21914c2e2ffff82541211c5bd43
Merge: feb29c5 c637e48
Author: Len Brown <len.brown@intel.com>
Date:   Sat Aug 14 23:55:57 2010 -0400

    Merge branch 'procfs-cleanup' into release

commit feb29c5175e61d0f1ec2cbcaccdfa55e588780be
Merge: f2a6618 2ff729d
Author: Len Brown <len.brown@intel.com>
Date:   Sat Aug 14 23:55:47 2010 -0400

    Merge branch 'apei' into release

commit f2a66185bed21427d8d347a42eaf0ad1d3d9fc63
Merge: 9fe6206 618d7fd
Author: Len Brown <len.brown@intel.com>
Date:   Sat Aug 14 23:55:44 2010 -0400

    Merge branch 'nvs' into release

commit c637e4861c7db8165d0f438db3829e7878c96059
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:17 2010 +0800

    ACPI: introduce module parameter acpi.aml_debug_output
    
    Introduce module parameter acpi.aml_debug_output.
    
    With acpi.aml_debug_output set, we can get AML debug object output
    (Store (AAA, Debug)), even with CONFIG_ACPI_DEBUG cleared.
    
    Together with the runtime custom method mechanism,
    we can debug AML code problems without rebuilding the kernel.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit a25ee9200eef07377e1703697afbb5d81f89e500
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Thu Jul 15 10:46:15 2010 +0800

    ACPI: introduce drivers/acpi/debugfs.c
    
    Introduce drivers/acpi/debugfs.c.
    
    Code for ACPI debugfs I/F,
    i.e. /sys/kernel/debug/acpi/custom_method,
    is moved to this file.
    
    And make ACPI debugfs always built in,
    even if CONFIG_ACPI_DEBUG is cleared.
    
    BTW:this adds about 400bytes code to ACPI, when
    CONFIG_ACPI_DEBUG is cleared.
    
    [uaccess.h build fix from Andrew Morton <akpm@linux-foundation.org>]
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 2ff729d506e8db82d76a93bc963df4d0a4d46b57
Author: Huang Ying <ying.huang@intel.com>
Date:   Thu Aug 12 11:55:17 2010 +0800

    ACPI, APEI, ERST debug support
    
    This patch adds debugging/testing support to ERST. A misc device is
    implemented to export raw ERST read/write/clear etc operations to user
    space. With this patch, we can add ERST testing support to
    linuxfirmwarekit ISO (linuxfirmwarekit.org) to verify the kernel
    support and the firmware implementation.
    
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 7ad6e9435596f692ff65f399da12816c94960185
Author: Huang Ying <ying.huang@intel.com>
Date:   Mon Aug 2 15:48:24 2010 +0800

    ACPI, APEI, Manage GHES as platform devices
    
    Register GHES during HEST initialization as platform devices. And make
    GHES driver into platform device driver. So that the GHES driver
    module can be loaded automatically when there are GHES available.
    
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit ad4ecef2f13c790f95b55320f2925c205d8f971f
Author: Huang Ying <ying.huang@intel.com>
Date:   Mon Aug 2 15:48:23 2010 +0800

    ACPI, APEI, Rename CPER and GHES severity constants
    
    The abbreviation of severity should be SEV instead of SER, so the CPER
    severity constants are renamed accordingly. GHES severity constants
    are renamed in the same way too.
    
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 2663b3f23537618c0c286551b138353fe26b3df8
Author: Huang Ying <ying.huang@intel.com>
Date:   Mon Aug 2 15:48:22 2010 +0800

    ACPI, APEI, Fix a typo of error path of apei_resources_request
    
    Fix a typo of error path of apei_resources_request. release_mem_region
    and release_region should be interchange.
    
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 28f4f8a9def2b1f3a6066bae791c77043ec49524
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Tue Aug 3 23:55:14 2010 +0200

    ACPI / ACPICA: Fix reference counting problems with GPE handlers
    
    If a handler is installed for a GPE associated with an AML method and
    such that it cannot wake up the system from sleep states, the GPE
    remains enabled after the handler has been installed, although it
    should be disabled in that case to avoid spurious execution of the
    handler.
    
    Fix this issue by making acpi_install_gpe_handler() disable GPEs
    that were previously associated with AML methods and cannot wake up
    the system from sleep states.
    
    Analogously, make acpi_remove_gpe_handler() enable the GPEs that
    are associated with AML methods after their handlers have been
    removed and cannot wake up the system from sleep states.  In addition
    to that, fix a code ordering issue in acpi_remove_gpe_handler() that
    renders the locking ineffective (ACPI_MTX_EVENTS is released
    temporarily in the middle of the routine to wait for the completion
    of events already in progress).
    
    For this purpose introduce acpi_raw_disable_gpe() and
    acpi_raw_enable_gpe() to be called with acpi_gbl_gpe_lock held
    and rework acpi_disable_gpe() and acpi_enable_gpe(), respectively, to
    use them.  Also rework acpi_gpe_can_wake() to use
    acpi_raw_disable_gpe() instead of calling acpi_disable_gpe() after
    releasing the lock to avoid the possible theoretical race with
    acpi_install_gpe_handler().
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: "Moore, Robert" <robert.moore@intel.com>
    Cc: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 108029ff84fcad8f9199d2d2e2583ae2747d45a4
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Jul 13 03:36:08 2010 +0000

    ACPI: Add the check of ADR flag in course of finding ACPI handle for PCI device
    
    The _ADR object is used to provide OSPM with the address of one device on its
    parent bus. In course of finding ACPI handle for the corresponding PCI device,
    we will firstly evaluate the _ADR object and then compare the two addresses to
    see whether it is the target ACPI device. But for one PCI device(0000:00:00.0)
    under the PCI root bridge, the corresponding address will be constructed as
    zero.In such case maybe the ACPI device without _ADR object will be misdetected
    and then be used to create the relationship between PCI device and ACPI device.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=16422
    
    Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 618d7fd0d4e51a45d25d9bc6097a0cb1e5a2f226
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Fri Jul 2 00:14:57 2010 +0200

    ACPI / Sleep: Drop acpi_suspend_finish()
    
    The function acpi_suspend_finish() is not necessary any more, because
    acpi_pm_finish() can be used instead of it just fine.  Remove it.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit c5f7a1bb65bca03253c189e946b3ca79669f08af
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Fri Jul 2 00:14:09 2010 +0200

    ACPI / Sleep: Consolidate suspend and hibernation routines
    
    Some hibernation and suspend routines can be merged, which reduces
    the complexity of code a bit.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 78f5f023167813130d2cf657d1b9eadc32f0e992
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Tue Jul 6 22:09:38 2010 -0400

    ACPI / Wakeup: Simplify enabling of wakeup devices
    
    To simplify the enabling of wakeup devices during system suspend and
    hibernation, merge acpi_enable_wakeup_device_prep() with
    acpi_disable_wakeup_device() and remove unnecessary (and no longer
    valid) comments from the latter.  Rename acpi_enable_wakeup_device()
    to acpi_enable_wakeup_devices() and acpi_disable_wakeup_device()
    to acpi_disable_wakeup_devices(), because these functions usually
    operate on multiple device objects.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 25bed55753b8cf243406e8837990b55946c5278d
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Fri Jul 2 00:12:26 2010 +0200

    ACPI / Sleep: Rework enabling wakeup devices
    
    There is no reason why acpi_enable_wakeup_device() should be called
    with interrupts disabled, because it doesn't access hardware.  Thus
    it is possible to move it next to acpi_enable_wakeup_device_prep()
    and make the ACPI suspend, hibernate and poweroff code more
    straightforward.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit e96c4b081df0991a57b244f68c3955a9ea00bd0a
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Tue Jul 6 18:28:35 2010 -0400

    ACPI / Sleep: Free NVS copy if suspending of devices fails
    
    If suspending of devices fails or system suspend is tested in the
    "devices" mode, the memory allocated for storing a copy of the ACPI
    NVS area will not be freed, because acpi_pm_finish() is not called
    in that case.  Fix this by moving the suspend_nvs_free() call to
    acpi_pm_end().
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>