linux-next: manual merge of the acpi tree

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got conflicts in
arch/x86/kernel/acpi/sleep.c between commits
3bf2e77453a87c22eb57ed4926760ac131c84459 ("x86, suspend, acpi: enter Big
Real Mode") and 065cb3dfe24978651caedfa54da585388ad15dde ("x86, suspend,
acpi: correct and add comments about Big Real Mode") from Linus' tree and
commit 60d40a50886415040888bde5133ccfeab40d945f ("x86 ACPI: normalize
segment descriptor register on resume") from the acpi tree (which also
appears to be in Linus' tree).

I used the version from Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the acpi tree

[Harvey Harrison]

CC'ing Andi whom I believe is looking after ACPI while Len is away.

On Wed, 2008-07-16 at 15:33 +1000, Stephen Rothwell wrote:
> Hi Len,
> 
> Today's linux-next merge of the acpi tree got conflicts in
> arch/x86/kernel/acpi/sleep.c between commits
> 3bf2e77453a87c22eb57ed4926760ac131c84459 ("x86, suspend, acpi: enter Big
> Real Mode") and 065cb3dfe24978651caedfa54da585388ad15dde ("x86, suspend,
> acpi: correct and add comments about Big Real Mode") from Linus' tree and
> commit 60d40a50886415040888bde5133ccfeab40d945f ("x86 ACPI: normalize
> segment descriptor register on resume") from the acpi tree (which also
> appears to be in Linus' tree).
> 
> I used the version from Linus' tree.

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
drivers/acpi/blacklist.c between commit
a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b ("ACPI: delete OSI(Linux) DMI
dmesg spam") from Linus' tree and commit
865596071bb89ec67a44b0ef2da172e0e733ce16 ("ACPI: delete OSI(Linux) DMI
dmesg spam") from the acpi tree.

The former had a slightly later commit time, so I used that.  Please fix
up the conflict in the acpi tree.

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

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

Re: linux-next: manual merge of the acpi tree

[Len Brown]

On Mon, 1 Dec 2008, Stephen Rothwell wrote:

> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a conflict in
> drivers/acpi/blacklist.c between commit
> a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b ("ACPI: delete OSI(Linux) DMI
> dmesg spam") from Linus' tree and commit
> 865596071bb89ec67a44b0ef2da172e0e733ce16 ("ACPI: delete OSI(Linux) DMI
> dmesg spam") from the acpi tree.
> 
> The former had a slightly later commit time, so I used that.  Please fix
> up the conflict in the acpi tree.

Hi Stephen,
Like linux-next, pulling the acpi tree into old copies of itself
doesn't work.

This is because I occasionally have to revise various patches and generate
"clean history" for the upstream pull into Linus' tree.
Also, I occasionally re-base branches within the tree up to
newer baselines so that they are easier to test vs upstream.

So if you pull the acpi tree into a copy of Linus' tree
then this type of conflict will go away.

thanks,
-Len

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

On Sun, 30 Nov 2008 21:55:38 -0500 (EST) Len Brown <lenb@kernel.org> wrote:
>
> So if you pull the acpi tree into a copy of Linus' tree
> then this type of conflict will go away.

And if you pull Linus' tree into the acpi tree the conflict will go away
as well ... but you (who understand the intention of the code) get to fix
it up rather than me (who is guessing).

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

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

Re: linux-next: manual merge of the acpi tree

[Len Brown]

> And if you pull Linus' tree into the acpi tree the conflict will go away
> as well ... but you (who understand the intention of the code) get to fix
> it up rather than me (who is guessing).

Your guess was correct -- the patch with the later commit time
was the correct one to keep.

This was my pilot error.  I updated the patch in my release tree
and so you got the updated patch via Linus.  But I failed to update
my test tree, so you got the old patch from my test tree.

I've just re-constituted my test branch, so the old patch is gone,
and with it this conflict.

thanks for pointing this out,
-Len

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

On Sun, 30 Nov 2008 23:11:50 -0500 (EST) Len Brown <lenb@kernel.org> wrote:
>
> Your guess was correct -- the patch with the later commit time
> was the correct one to keep.
> 
> This was my pilot error.  I updated the patch in my release tree
> and so you got the updated patch via Linus.  But I failed to update
> my test tree, so you got the old patch from my test tree.
> 
> I've just re-constituted my test branch, so the old patch is gone,
> and with it this conflict.

OK, thanks.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/kernel/acpi/sleep.c between commit
3038edabf48f01421c621cb77a712b446d3a5d67 ("x86 ACPI: fix breakage of
resume on 64-bit UP systems with SMP kernel") from Linus' tree and commit
d0d0f7432c9cbd52cb2f31d499f8292b13a7ecac ("x86: remove magic number from
ACPI sleep stack buffer") from the acpi tree.

Just overlapping context.  I fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/acpi/sleep.c
index c44cd6d,55d10cb..0000000
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@@ -98,9 -97,7 +98,9 @@@ int acpi_save_state_mem(void
  #else /* CONFIG_64BIT */
  	header->trampoline_segment = setup_trampoline() >> 4;
  #ifdef CONFIG_SMP
- 	stack_start.sp = temp_stack + 4096;
+ 	stack_start.sp = temp_stack + sizeof(temp_stack);
 +	early_gdt_descr.address =
 +			(unsigned long)get_cpu_gdt_table(smp_processor_id());
  #endif
  	initial_code = (unsigned long)wakeup_long64;
  	saved_magic = 0x123456789abcdef0;

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
drivers/pnp/quirks.c between commit
2e532d68a2b3e2aa6b19731501222069735c741c ("{pci,pnp} quirks.c: don't use
deprecated print_fn_descriptor_symbol()") from Linus' tree and commit
2f53432c2aedbe79020e44525eb069d9138a01dd ("PNP: convert to using pnp_dbg
()") from the acpi tree.

I used the acpi tree version (since it was just a follow on from Linus'
version).

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
drivers/pnp/Makefile between commit
ed458df4d2470adc02762a87a9ad665d0b1a2bd4 ("PnP: move pnpacpi/pnpbios_init
to after PCI init") from Linus' tree and commit
ac88a8f3f7df04774b386ddaf586040adb819b58 ("PNP: remove old
CONFIG_PNP_DEBUG option") from the acpi tree.

Really just a context problem.  I fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc drivers/pnp/Makefile
index e83f34f,a381a92..0000000
--- a/drivers/pnp/Makefile
+++ b/drivers/pnp/Makefile
@@@ -7,10 -7,3 +7,6 @@@ obj-y		:= core.o card.o driver.o resour
  obj-$(CONFIG_PNPACPI)		+= pnpacpi/
  obj-$(CONFIG_PNPBIOS)		+= pnpbios/
  obj-$(CONFIG_ISAPNP)		+= isapnp/
 +
 +# pnp_system_init goes after pnpacpi/pnpbios init
 +obj-y				+= system.o
- 
- ifeq ($(CONFIG_PNP_DEBUG),y)
- EXTRA_CFLAGS += -DDEBUG
- endif

Re: linux-next: manual merge of the acpi tree

[Bjorn Helgaas]

On Tuesday 14 October 2008 10:23:53 pm Stephen Rothwell wrote:
> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a conflict in
> drivers/pnp/Makefile between commit
> ed458df4d2470adc02762a87a9ad665d0b1a2bd4 ("PnP: move pnpacpi/pnpbios_init
> to after PCI init") from Linus' tree and commit
> ac88a8f3f7df04774b386ddaf586040adb819b58 ("PNP: remove old
> CONFIG_PNP_DEBUG option") from the acpi tree.
> 
> Really just a context problem.  I fixed it up (see below).

Your fixup looks good, thanks.

Bjorn

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in MAINTAINERS
between commit 4fa971811cda4036d84574bfb38bd9b22b5c35ec ("MN10300: MEI
are renaming themselves to Panasonic") from Linus' tree and commit
709ee531c153038d81b30649b9eeed3c44a4d5cc ("panasonic-laptop: add
Panasonic Let's Note laptop extras driver v0.94") from the acpi tree.

Just overlapping addition/move.  I fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc MAINTAINERS
index 5d0b8a2,f9f6d4b..0000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -3161,15 -3153,11 +3167,20 @@@ M:	olof@lixom.ne
  L:	i2c@lm-sensors.org
  S:	Maintained
  
+ PANASONIC LAPTOP ACPI EXTRAS DRIVER
+ P:	Harald Welte
+ M:	laforge@gnumonks.org
+ S:	Maintained
+ 
 +PANASONIC MN10300/AM33 PORT
 +P:	David Howells
 +M:	dhowells@redhat.com
 +P:	Koichi Yasutake
 +M:	yasutake.koichi@jp.panasonic.com
 +L:	linux-am33-list@redhat.com (moderated for non-subscribers)
 +W:	ftp://ftp.redhat.com/pub/redhat/gnupro/AM33/
 +S:	Maintained
 +
  PARALLEL PORT SUPPORT
  L:	linux-parport@lists.infradead.org (subscribers-only)
  S:	Orphan

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the acpi tree got a conflict in
drivers/misc/acer-wmi.c between commit
83097aca8567a0bd593534853b71fe0fa9a75d69 ("Fix oops in acer_wmi driver
(acer_wmi_init)") from Linus' tree and commit
017f8ecd1cedb482392f0500ee3701b8c50a46f9 ("Acer-WMI: fingers off
backlight if video.ko is serving this functionality") from the acpi tree.

Just overlapping additions.  I fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc drivers/misc/acer-wmi.c
index c6c77a5,6df52e8..0000000
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@@ -1240,8 -1246,12 +1249,14 @@@ static int __init acer_wmi_init(void
  		return -ENODEV;
  	}
  
 +	set_quirks();
 +
+ 	if (!acpi_video_backlight_support() && has_cap(ACER_CAP_BRIGHTNESS)) {
+ 		interface->capability &= ~ACER_CAP_BRIGHTNESS;
+ 		printk(ACER_INFO "Brightness must be controlled by "
+ 		       "generic video driver\n");
+ 	}
+ 
  	if (platform_driver_register(&acer_platform_driver)) {
  		printk(ACER_ERR "Unable to register platform driver.\n");
  		goto error_platform_register;

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/mm/srat_32.c against Linus' tree.

I used the version in Linus' tree.  Could you do a merge with Linus' tree
for tomorrow?

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

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

Re: linux-next: manual merge of the acpi tree

[Adrian Bunk]

On Thu, Jul 17, 2008 at 02:22:05PM +1000, Stephen Rothwell wrote:
> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a conflict in
> arch/x86/mm/srat_32.c against Linus' tree.
> 
> I used the version in Linus' tree.  Could you do a merge with Linus' tree
> for tomorrow?

You seem to still pull Len's tree?

> Cheers,

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Adrian, Andi,

On Thu, 17 Jul 2008 10:24:49 +0300 Adrian Bunk <bunk@kernel.org> wrote:
>
> On Thu, Jul 17, 2008 at 02:22:05PM +1000, Stephen Rothwell wrote:
> > Hi Len,
> > 
> > Today's linux-next merge of the acpi tree got a conflict in
> > arch/x86/mm/srat_32.c against Linus' tree.
> > 
> > I used the version in Linus' tree.  Could you do a merge with Linus' tree
> > for tomorrow?
> 
> You seem to still pull Len's tree?

Until I am told otherwise ...

Last I had was this (on July 7):

-----------------------------------------------------------------------
sfr wrote:
> Andi Kleen wrote:
>
> > >> git://git.kernel.org/pub/scm/git/linux/kernel/ak/linux-acpi-2.6.git test
> > > 
> > > Then why is linux-next tracking that?
> > 
> > It is tracking Len's tree not mine, right?
> 
> /me hits himself in the head :-)
> 
> Sorry about that.
> 
> > Or did you switch already to mine?
> 
> No, I only do what is asked of me :-)
-----------------------------------------------------------------------

And so since I have no idea what tree to track and it seems to have
been merged to Linus anyway. I have dropped the ACPI tree until someone
straigtens me out.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/kernel/process.c between commit
aa276e1cafb3ce9d01d1e837bcd67e92616013ac ("x86, clockevents: add C1E
aware idle function") from linus' tree and commit
dbce8340e4549b612ac74fc7175721f9aed67b62 ("ACPI: Create "idle=halt"
bootparam") from the acpi tree (which is also in Linus' tree).

Just overlapping additions.  A merge of Linus' tree will make it go away.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
Documentation/ABI/testing/sysfs-firmware-acpi.

It was just white space different from Linus' tree.

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

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

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

On Thu, 17 Jul 2008 14:00:19 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the acpi tree got a conflict in
> Documentation/ABI/testing/sysfs-firmware-acpi.
> 
> It was just white space different from Linus' tree.

This was true of several other files as well.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/kernel/process.c between commit
aa276e1cafb3ce9d01d1e837bcd67e92616013ac ("x86, clockevents: add C1E
aware idle function") from the x86 tree and commits
dbce8340e4549b612ac74fc7175721f9aed67b62 ("ACPI: Create "idle=halt"
bootparam") from the acpi tree.

Just a case of overlapping additions.  I did the obvious fixup and can
carry it.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a trivial conflict in
include/acpi/acpi_bus.h between commit
eb9d0fe40e313c0a74115ef456a2e43a6c8da72f ("PCI ACPI: Rework PCI handling
of wake-up") from the acpi tree and commit
be9c73564e69729cda9ad2b3258eb0375d92a49c ("ACPI PM:
acpi_pm_device_sleep_state() cleanup") from the acpi tree (which is also
in the pci tree).

Its just an addition overlapping an unrelated change.  I can carry the
fixup.

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

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

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

On Tue, 8 Jul 2008 13:03:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the acpi tree got a trivial conflict in
> include/acpi/acpi_bus.h between commit
> eb9d0fe40e313c0a74115ef456a2e43a6c8da72f ("PCI ACPI: Rework PCI handling
> of wake-up") from the acpi tree and commit
                        ^^^^
pci

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got conflicts in
drivers/pci/pci.c and drivers/pci/pci.h between commit
961d9120fa6f078492a1c762dd91f2c097e56c83 ("PCI: Introduce
platform_pci_power_manageable function") from the pci tree and commit
d40f76ca5c165c9ff1490bbbdb34c520d7155c1f ("PCI ACPI: Drop the second
argument of platform_pci_choose_state") from the acpi tree (which is also
in the pci tree).

The former removes the code that the latter modifies.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the acpi tree

[Rafael J. Wysocki]

On Tuesday, 8 of July 2008, Stephen Rothwell wrote:
> Hi Len,
> 
> Today's linux-next merge of the acpi tree got conflicts in
> drivers/pci/pci.c and drivers/pci/pci.h between commit
> 961d9120fa6f078492a1c762dd91f2c097e56c83 ("PCI: Introduce
> platform_pci_power_manageable function") from the pci tree and commit
> d40f76ca5c165c9ff1490bbbdb34c520d7155c1f ("PCI ACPI: Drop the second
> argument of platform_pci_choose_state") from the acpi tree (which is also
> in the pci tree).
> 
> The former removes the code that the latter modifies.

It should be safe to drop commit d40f76ca5c165c9ff1490bbbdb34c520d7155c1f
("PCI ACPI: Drop the second argument of platform_pci_choose_state") from the
ACPI tree.

Should I prepare a revert patch?

Rafael

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len, Ingo,

Today's linux-next merge of the acpi tree got a conflict in
Documentation/kernel-parameters.txt between commits "ACPI : Create
"idle=nomwait" bootparam" and "ACPI: Create "idle=halt" bootparam"
different version of which appear in the x86 and acpi trees ("ACPI :
Create "idle=nomwait" bootparam" in the acpi tree is different from the
version that was in that tree on Friday (thus this conflict comes up
again)).

Please sort this out ...

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

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

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

On Mon, 30 Jun 2008 15:59:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Len, Ingo,
> 
> Today's linux-next merge of the acpi tree got a conflict in
> Documentation/kernel-parameters.txt between commits "ACPI : Create
> "idle=nomwait" bootparam" and "ACPI: Create "idle=halt" bootparam"
> different version of which appear in the x86 and acpi trees ("ACPI :
> Create "idle=nomwait" bootparam" in the acpi tree is different from the
> version that was in that tree on Friday (thus this conflict comes up
> again)).
> 
> Please sort this out ...

This also caused conflicts in arch/ia64/kernel/process.c,
arch/x86/kernel/process.c, drivers/acpi/processor_core.c,
include/asm-ia64/processor.h and include/asm-x86/processor.h.

I fixed it up by using the acpi tree's versions.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> On Mon, 30 Jun 2008 15:59:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Len, Ingo,
> > 
> > Today's linux-next merge of the acpi tree got a conflict in 
> > Documentation/kernel-parameters.txt between commits "ACPI : Create 
> > "idle=nomwait" bootparam" and "ACPI: Create "idle=halt" bootparam" 
> > different version of which appear in the x86 and acpi trees ("ACPI : 
> > Create "idle=nomwait" bootparam" in the acpi tree is different from 
> > the version that was in that tree on Friday (thus this conflict 
> > comes up again)).
> > 
> > Please sort this out ...
> 
> This also caused conflicts in arch/ia64/kernel/process.c,
> arch/x86/kernel/process.c, drivers/acpi/processor_core.c,
> include/asm-ia64/processor.h and include/asm-x86/processor.h.
> 
> I fixed it up by using the acpi tree's versions.

hm, this was caused by the ACPI tree doing a non-append rebase instead 
of the trivial delta fix like the one below. I've added the one below to 
the x86 tree.

	Ingo

----------------->
commit 4fb0b0af57439fa62cf24a39b65f6b6ba148fba6
Author: Ingo Molnar <mingo@elte.hu>
Date:   Mon Jun 30 11:00:59 2008 +0200

    doc: Documentation/kernel-parameters.txt, fix whitespace
    
    based on:
    
    | commit ce4bd94fad0fa934c0de1ba1932e7e61bc142176
    | Author: Zhao Yakui <yakui.zhao@intel.com>
    | Date:   Fri Jun 20 03:44:11 2008 -0400
    |
    |     ACPI : Create "idle=nomwait" bootparam
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 39baaba..0f7268a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,7 +785,7 @@ and is between 256 and 4096 characters. It is defined in the file
 			See Documentation/ide/ide.txt.
 
 	idle=		[X86]
-			Format: idle=poll or idle=mwait, idle = halt, idle=nomwait
+			Format: idle=poll or idle=mwait, idle=halt, idle=nomwait
 			Poll forces a polling idle loop that can slightly improves the performance
 			of waking up a idle CPU, but will use a lot of power and make the system
 			run hot. Not recommended.
@@ -793,9 +793,9 @@ and is between 256 and 4096 characters. It is defined in the file
 			to not use it because it doesn't save as much power as a normal idle
 			loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
 			as idle=poll.
-			idle = halt . Halt is forced to be used for CPU idle.
+			idle=halt . Halt is forced to be used for CPU idle.
 			In such case C2/C3 won't be used again.
-			idle = nomwait. disable Mwait for CPU C-state.
+			idle=nomwait. disable Mwait for CPU C-state.
 			In such case C2C3_FFH access mode will be disabled.
 
 	ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
Documentation/kernel-parameters.txt between commits
2366d29ac4521f48150ec5d6d5242a583a8a2ec1 ("ACPI: Create "idle=halt" boot
parameter") and 2fa517a2fa9ade5c4f41b6334fa8a20d7f1f8dd0 ("ACPI : Create
"idle=nomwait" bootparam") from the x86 tree and commits
4c8a298d35db029da3d6c9e1a0ed5acbf1764743 ("ACPI: Create "idle=halt" boot
parameter") and ce4bd94fad0fa934c0de1ba1932e7e61bc142176 ("ACPI : Create
"idle=nomwait" bootparam") from the acpi tree.

Same patches with slightly different white space ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a trivial conflict in
arch/x86/kernel/srat_32.c between commit
885aa5a57fe7c9d7f2c481e1107c3376384dc125 ("x86: numa32 pfn print out
using hex instead") from the x86 tree and commit
5e3d42c632c715fa3076175c39e834223b10c47a ("ACPICA: Update DMAR and SRAT
table definitions") from the acpi tree.

They both changed what a printk was printing.  I fixed it up.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/kernel/srat_32.c between commit
9920a004626a2dc2980693d634e4000f086cb283 ("x86: use acpi_numa_init to
parse on 32-bit numa") from the  tree and commit
a27557c76c6e092ec886f0e3e443f3190f0b0fcc ("ACPICA: Eliminate
acpi_native_uint type") from the acpi tree.

The code modified by the latter was removed by the former.  So I used the
former.

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

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

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a conflict in 
> arch/x86/kernel/srat_32.c between commit 
> 9920a004626a2dc2980693d634e4000f086cb283 ("x86: use acpi_numa_init to 
> parse on 32-bit numa") from the tree and commit 
> a27557c76c6e092ec886f0e3e443f3190f0b0fcc ("ACPICA: Eliminate 
> acpi_native_uint type") from the acpi tree.
> 
> The code modified by the latter was removed by the former.  So I used 
> the former.

thanks Stephen.

I suspect we cannot really eliminate this particular conflict because 
the latter change is a (much welcome!) infrastructure cleanup in all 
things ACPI, the former is an early init refactoring/cleanup that 
depends on a whole lot of other (non-ACPI) changes in tip/x86/*. It's
too late in .26-rc cycle to push the infrastructure cleanup upstream, so
i suspect we have to live with this conflict for a while.

	Ingo

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

On Wed, 25 Jun 2008 09:15:08 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> I suspect we cannot really eliminate this particular conflict because 
> the latter change is a (much welcome!) infrastructure cleanup in all 
> things ACPI, the former is an early init refactoring/cleanup that 
> depends on a whole lot of other (non-ACPI) changes in tip/x86/*. It's
> too late in .26-rc cycle to push the infrastructure cleanup upstream, so
> i suspect we have to live with this conflict for a while.

No problem.  How long can it be until all this is merged in Linus' tree
anyway? :-)

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

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

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> On Wed, 25 Jun 2008 09:15:08 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > I suspect we cannot really eliminate this particular conflict 
> > because the latter change is a (much welcome!) infrastructure 
> > cleanup in all things ACPI, the former is an early init 
> > refactoring/cleanup that depends on a whole lot of other (non-ACPI) 
> > changes in tip/x86/*. It's too late in .26-rc cycle to push the 
> > infrastructure cleanup upstream, so i suspect we have to live with 
> > this conflict for a while.
> 
> No problem.  How long can it be until all this is merged in Linus' 
> tree anyway? :-)

if Len acks these patches i can do a by-line mini-topic with just these 
commits and put them into tip/auto-x86-next. It's Len's call though :-)

	Ingo

Re: linux-next: manual merge of the acpi tree

[Len Brown]

On Wed, 25 Jun 2008, Ingo Molnar wrote:

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Wed, 25 Jun 2008 09:15:08 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > I suspect we cannot really eliminate this particular conflict 
> > > because the latter change is a (much welcome!) infrastructure 
> > > cleanup in all things ACPI, the former is an early init 
> > > refactoring/cleanup that depends on a whole lot of other (non-ACPI) 
> > > changes in tip/x86/*. It's too late in .26-rc cycle to push the 
> > > infrastructure cleanup upstream, so i suspect we have to live with 
> > > this conflict for a while.
> > 
> > No problem.  How long can it be until all this is merged in Linus' 
> > tree anyway? :-)
> 
> if Len acks these patches i can do a by-line mini-topic with just these 
> commits and put them into tip/auto-x86-next. It's Len's call though :-)

Ingo,
can you point me tot he patches you'd like me to review/ack?

I don't understand how you propose to void a linux-next merge conflict --
unless you're going to cherry-pick the ACPICA changes into your tree?

thanks,
-Len

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Len Brown <lenb@kernel.org> wrote:

> 
> 
> On Wed, 25 Jun 2008, Ingo Molnar wrote:
> 
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > On Wed, 25 Jun 2008 09:15:08 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > > >
> > > > I suspect we cannot really eliminate this particular conflict 
> > > > because the latter change is a (much welcome!) infrastructure 
> > > > cleanup in all things ACPI, the former is an early init 
> > > > refactoring/cleanup that depends on a whole lot of other (non-ACPI) 
> > > > changes in tip/x86/*. It's too late in .26-rc cycle to push the 
> > > > infrastructure cleanup upstream, so i suspect we have to live with 
> > > > this conflict for a while.
> > > 
> > > No problem.  How long can it be until all this is merged in Linus' 
> > > tree anyway? :-)
> > 
> > if Len acks these patches i can do a by-line mini-topic with just these 
> > commits and put them into tip/auto-x86-next. It's Len's call though :-)
> 
> Ingo,
> can you point me tot he patches you'd like me to review/ack?
> 
> I don't understand how you propose to void a linux-next merge conflict 
> -- unless you're going to cherry-pick the ACPICA changes into your 
> tree?

sorry, i was thinking about a different issue - you are right that in 
this case there's little we can do.

I was thinking about these:

 acpi-acpi_numa_init-build-fix
 ia64, acpi: fix Altix boot breakage in ACPI
 acpi: fix boot breakage on Altix

note that this build failure does _not_ occur with current mainline, so 
it's a linux-next issue.

i've prepared a tip/acpi-for-len branch for you so that you can have a 
look at these, you can pull them from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git acpi-for-len

Thanks,

	Ingo

------------------>
Ingo Molnar (1):
      acpi: NR_NODE_MEMBLKS build fix

Russ Anderson (2):
      ia64, acpi: fix Altix boot breakage in ACPI
      acpi: fix boot breakage on Altix, #2

 arch/ia64/Kconfig    |    4 ++++
 drivers/acpi/numa.c  |    4 ++++
 include/linux/acpi.h |    2 +-
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 16be414..1be94eb 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -60,6 +60,10 @@ config RWSEM_XCHGADD_ALGORITHM
 	bool
 	default y
 
+config HAVE_ARCH_PARSE_SRAT
+	bool
+	default y
+
 config ARCH_HAS_ILOG2_U32
 	bool
 	default n
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 658e5f3..0fb4d2a 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -199,6 +199,7 @@ acpi_parse_processor_affinity(struct acpi_subtable_header * header,
 	return 0;
 }
 
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 static int __init
 acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 			   const unsigned long end)
@@ -216,6 +217,7 @@ acpi_parse_memory_affinity(struct acpi_subtable_header * header,
 
 	return 0;
 }
+#endif
 
 static int __init acpi_parse_srat(struct acpi_table_header *table)
 {
@@ -244,9 +246,11 @@ int __init acpi_numa_init(void)
 	if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
 				      acpi_parse_processor_affinity, NR_CPUS);
+#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
 		acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 				      acpi_parse_memory_affinity,
 				      NR_NODE_MEMBLKS);
+#endif
 	}
 
 	/* SLIT: System Locality Information Table */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 41f7ce7..b426ac5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -93,7 +93,7 @@ int acpi_parse_mcfg (struct acpi_table_header *header);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
-#ifdef CONFIG_HAVE_ARCH_PARSE_SRAT
+#if defined(CONFIG_HAVE_ARCH_PARSE_SRAT) && !defined(NR_NODE_MEMBLKS)
 #define NR_NODE_MEMBLKS MAX_NUMNODES
 #define acpi_numa_slit_init(slit) do {} while (0)
 #define acpi_numa_processor_affinity_init(pa) do {} while (0)

Re: linux-next: manual merge of the acpi tree

[Len Brown]

> I was thinking about these:
> 
>  acpi-acpi_numa_init-build-fix
>  ia64, acpi: fix Altix boot breakage in ACPI
>  acpi: fix boot breakage on Altix
> 
> note that this build failure does _not_ occur with current mainline, so 
> it's a linux-next issue.
> 
> i've prepared a tip/acpi-for-len branch for you so that you can have a 
> look at these, you can pull them from:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git acpi-for-len

I can see these on the web, but i've got no idea how to traverse
your tip tree by actually pulling it.  It seems to be a maze of branches,
and it isn't clear how to find the one i want. 

are the 2nd and 3rd patches in response to the 1st patch?
is the 1st patch fixing something that happens in real life,
or a random build failuire that only a computer can find?

without understanding those, my impression is that i'm not
really excited about more config options and more ifdefs in C-code.
I'd prefer less of both.

-Len

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Len Brown <lenb@kernel.org> wrote:

> 
> 
> > I was thinking about these:
> > 
> >  acpi-acpi_numa_init-build-fix
> >  ia64, acpi: fix Altix boot breakage in ACPI
> >  acpi: fix boot breakage on Altix
> > 
> > note that this build failure does _not_ occur with current mainline, so 
> > it's a linux-next issue.
> > 
> > i've prepared a tip/acpi-for-len branch for you so that you can have a 
> > look at these, you can pull them from:
> > 
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git acpi-for-len
> 
> I can see these on the web, but i've got no idea how to traverse your 
> tip tree by actually pulling it.  It seems to be a maze of branches, 
> and it isn't clear how to find the one i want.

the thing you want to look at this is to use the URI above:

   git-pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git acpi-for-len

it's based on -git, so it pulls in no other unrelated changes.

> are the 2nd and 3rd patches in response to the 1st patch? is the 1st 
> patch fixing something that happens in real life, or a random build 
> failuire that only a computer can find?

the build failure happens on allyesconfig as well. (but obviously we 
want to fix 'random' failures just as much - even if most users would be 
unlikely to find a particular config combination - to make the kernel 
more testable.)

	Ingo

Re: linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

On Wed, 25 Jun 2008 14:20:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the acpi tree got a conflict in
> arch/x86/kernel/srat_32.c between commit
> 9920a004626a2dc2980693d634e4000f086cb283 ("x86: use acpi_numa_init to
> parse on 32-bit numa") from the  tree and commit
                                  ^
x86

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a trivial conflict in
arch/x86/kernel/process.c between commit
8750bf598db6a0ea3475d1cf8da922b325941e12 ("x86: add C1E aware idle
function") from the x86 tree and commit
5ffc8862cc917ae5107049f3c5fd549fb6c19cac ("ACPI : Create "idle=nomwait"
bootparam") from the acpi tree.

It was just a case of overlapping additions of includes.  So I took both.

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

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

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
arch/x86/kernel/process.c between commit
8750bf598db6a0ea3475d1cf8da922b325941e12 ("x86: add C1E aware idle
function") from the x86 tree and commits
bd08eac673842bab79ddaec048012b6e5d4074fd ("ACPI: Create "idle=halt" boot
parameter") and 5ffc8862cc917ae5107049f3c5fd549fb6c19cac ("ACPI : Create
"idle=nomwait" bootparam") from the acpi tree.

This is just an overlapping additions problem, so I took both in the
obvious manner.

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

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

Re: linux-next: manual merge of the acpi tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a conflict in
> arch/x86/kernel/process.c between commit
> 8750bf598db6a0ea3475d1cf8da922b325941e12 ("x86: add C1E aware idle
> function") from the x86 tree and commits
> bd08eac673842bab79ddaec048012b6e5d4074fd ("ACPI: Create "idle=halt" boot
> parameter") and 5ffc8862cc917ae5107049f3c5fd549fb6c19cac ("ACPI : Create
> "idle=nomwait" bootparam") from the acpi tree.
> 
> This is just an overlapping additions problem, so I took both in the 
> obvious manner.

thanks Stephen. I've cherry-picked the two ACPI commits into 
tip/x86/cpu, to make future merges easier.

	Ingo

linux-next: manual merge of the acpi tree

[Stephen Rothwell]

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

Hi Len,

Today's linux-next merge of the acpi tree got a trivial conflict in
drivers/acpi/sleep/main.c between commit
d8f3de0d2412bb91639cfefc5b3c79dbf3812212 ("Suspend-related patches for
2.6.27") from the pci tree and commit
4fe0a2f25ed36949330dbda0154a4a701f310462 ("ACPICA: Lindent") from the
acpi tree.

The latter was just updating some code that the former removed.

A general comment on Lindent: it is worth checking the output.  Both the
conflicts were because it removed the space from in front of a '?'
operator - which I consider fairly bogus.

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

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