Some of these may not have seen review on linux-pci, so I'm sending them out

for comment before I send Linus the pull request.
Any comments/objections?
The biggest patch by far is the resource_wc stuff; it should have been pushed

earlier, but for some reason I thought Ingo & co. were going to do that...
Thanks,

Jesse
commit a123c3d9643464c56417680536ed9515f15cffa1

Author: Yinghai Lu <Yinghai.Lu@Sun.COM>

Date:   Mon May 12 21:21:05 2008 +0200
    PCI: use dev_to_node in pci_call_probe
    to make sure get one online node.
    Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

    Signed-off-by: Ingo Molnar <mingo@elte.hu>

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c

index 72cf61e..e1637bd 100644

--- a/drivers/pci/pci-driver.c

+++ b/drivers/pci/pci-driver.c

@@ -181,7 +181,7 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,

 	   any need to change it. */

 	struct mempolicy *oldpol;

 	cpumask_t oldmask = current->cpus_allowed;

-	int node = pcibus_to_node(dev->bus);

+	int node = dev_to_node(&dev->dev);
 	if (node >= 0) {

 		node_to_cpumask_ptr(nodecpumask, node);
commit d99f75679d17ada3e90a04c50605f90a6a590e45

Author: Miquel van Smoorenburg <mikevs@xs4all.net>

Date:   Thu Jun 5 18:14:44 2008 +0200
    x86/PCI: pci-dma.c: don't always add __GFP_NORETRY to gfp
    Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY

    to the allocation flags, because it wants to be reasonably

    sure not to deadlock when calling alloc_pages().
    But really that should only be done in two cases:

    - when allocating memory in the lower 16 MB DMA zone.

      If there's no free memory there, waiting or OOM killing is of no use

    - when optimistically trying an allocation in the DMA32 zone

      when dma_mask < DMA_32BIT_MASK hoping ...
[ message continues ]

Although I quite appreciate the addition of patches, IMO it would be

easier to read if the patch descriptions and patches were not mixed

together.
Most 'git pull' things I've seen include a changeset summary (shortlog)

and cumulative patch, when its a single email.  Sometimes (i.e. GregKH

and a few others) the individual patches are posted in separate emails.
Either way, it saves one from having to wade through a long email, just

to get an idea of the sum total of the changes...
Regards,
	Jeff
--

Right, I probably should have used one of the git mail scripts... but this

wasn't a real git pull request either, more of a "hey please sanity check

this" type thing.  I figured in this case keeping the changelogs was

important, but didn't want to spam people with a bunch of messages when the

total size really wasn't that big...
Jesse

--

Hi Jesse,
A bunch of THREADED messages are quite easy to skip (single keystroke for me).
So just use one of those git mail scripts, which can do threading

and everyone is happy.
Best Regards
Ingo Oeser, wading through lkml since >10 years.

--